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Abstract 

A typed model of strategic term rewriting is developed. The key innovation is that generic 
traversal is covered. To this end, we define a typed rewriting calculus S"^. The calculus 
employs a many-sorted type system extended by designated generic strategy types 7. We 
consider two generic strategy types, namely the types of type-preserving and type-unifying 
strategies. S!y offers traversal combinators to construct traversals or schemes thereof from 
many-sorted and generic strategies. The traversal combinators model different forms of 
one-step traversal, that is, they process the immediate subterms of a given term without 
anticipating any scheme of recursion into terms. To inhabit generic types, we need to add 
a fundamental combinator to lift a many-sorted strategy s to a generic type 7. This step 
is called strategy extension. The semantics of the corresponding combinator states that s 
is only applied if the type of the term at hand fits, otherwise the extended strategy fails. 
This approach dictates that the semantics of strategy application must be type-dependent 
to a certain extent. Typed strategic term rewriting with coverage of generic term traversal 
is a simple but expressive model of generic programming. It has applications in program 
transformation and program analysis. 
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1 Preface 



Strategic programming Term rewriting strategies are of prime importance for 
the implementation of term rewriting systems. In the present paper, we focus on an- 
other application of strategies, namely on their utility for programming. Strategies 
can be used to describe evaluation and normalisation strategies, e.g., to explicitly 
control rewriting for a system that is not confluent or terminating. Moreover, strate- 
gies can be used to perform traversal, and to describe reusable traversal schemes. In 
fact, the typeful treatment of generic traversal is the primary subject of the present 
paper. To perform traversal in standard rewriting without extra support for traver- 
sal, one has to resort to auxiliary function symbols, and rewrite rules have to be 
used to encode the actual traversal for the signature at hand. This usually implies 
one rewrite rule per term constructor, per traversal. This problem has been identi- 
fied in [ |BSV97i ICVKOq , [BSVbq , IBKVOU lyiiOTI ] from different points of 
view. In a framework, where traversal strategies are supported, the programmer can 
focus on the term patterns which require problem-specific treatment. All the other 
patterns can be covered once and for all by the generic part of a suitable strategy. 



Application potential Language concepts for generic term traversal support an 
important dimension of generic programming which is useful, for example, for the 
implementation of program transformations and program analyses. Such function- 
ality is usually very uniform for most patterns in the traversed syntax. In [ |VisOO| ], 
untyped, suitably parameterised traversal strategies are used to capture algorithms 
for free variable collection, substitution, unification in a generic, that is, language- 
independent manner. In [ |LV01| ], typed traversal strategies are employed for the 
specification of refactorings for object-oriented programs in a concise manner. 
There are further ongoing efforts to apply term rewriting strategies to the modu- 
lar development of interpreters, to language-independent refactoring, to grammar 
engineering, and others. 



S'^ and relatives In the present paper, the rewriting calculus S'^^ is developed. The 
calculus corresponds to a simple but expressive language for generic programming. 
The design of S'^ was influenced by existing rewriting frameworks with support for 
strategies as opposed to frameworks which assume a fixed built-in strategy for nor- 
malisation / evaluation. Strategies are supported, for example, by the specification 
formalisms Maude [ |CHLM96| , |CDE^99D and ELAN [gKK^, |BKKRU1| ]. The 
p-calculus [ |CK99| ] provides an abstract model for rewriting including the defini- 
tion of strategies. The programming language Stratego [ |VBT98| ] based on system 
S [ |VB98| ] is entirely devoted to strategic programming. In fact, the "S"' in S'^ refers 
to system S which was most influential in the design of S'^. The ""' in S'^ indicates 
that even the untyped part of S'^ does not coincide with system S. The "7" in S'^ 
stands for the syntactical domain 7 of generic strategy types. The idea of rewriting 
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Input tree 




Traversals 





(I) (II) t (III) ^ (IV) >^ ^^(V) 

b true [3,5] 2 




Fig. 1 . Illustration of generic traversal 



strategies goes back to Paulson's work on higher-order implementation of rewriting 



strategies QPauSBQ in the context of the implementation of tactics and tacticals for 
theorem proving. The original contribution of S'^ is the typeful approach to generic 
traversal strategies in a many -sorted setting of term rewriting. 



Examples of generic traversal In Figure 1, five examples (I)-(V) of intention- 
ally generic traversal are illustrated. In (I), all naturals in the given term (say, tree) 
are incremented as modelled by the rewrite rule N succ{N). We need to turn 
this rule into a traversal strategy because the rule on its own is not terminating when 
considered as a rewrite system. The strategy should be generic, that is, it should be 
applicable to terms of any sort. In (II), a particular pattern is rewritten according to 
the rewrite rule g{P) g'{P)- Assume that we want to control this replacement so 
that it is performed in bottom-up manner, and the first (i.e., bottom-most) matching 
term is rewritten only. Indeed, in Figure 1, only one g is turned into a g', namely 
the deeper one. The strategy to locate the desired node in the term is completely 
generic. While (I)-(II) require type-preserving traversal, (III)-(V) require type- 
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changing traversal. We say that type-unifying traversal [ P^VKOOQ is needed because 
the results of (III)-(V) are of a fixed, say a unified type. In (III), we test some 
property of the term, namely if naturals occur at all. The result is of type Boolean. 
In (IV), we collect all the naturals in the term using a left-to-right traversal. That 
is, the result is a list of integers. Finally, in (V), we count all the occurrences of the 
function symbol g. 

The tension between genericity and specificity In addition to a purely many- 
sorted type system, the rewriting calculus S'^ offers two designated generic strat- 
egy types, namely the type TP denoting generic type-preserving strategies, and the 
type TU(t) denoting generic type-unifying strategies with the unified result type 
r. Generic traversal strategies typically employ many-sorted rewrite rules. Hence, 
we need to cope with both many-sorted and generic types, and we somehow need 
to mediate between the two levels. Since a traversal strategy must be applicable to 
terms of any sort, many-sorted ingredients must be lifted in some way to a generic 
type before they can be used in a generic context. As a matter of fact, a traversal 
strategy might attempt to apply lifted many-sorted ingredients to subterms of dif- 
ferent sorts. For the sake of type safety, we have to ensure that many-sorted ingre- 
dients are only applied to terms of the appropriate sort. Si^ offers a corresponding 
type-safe combinator for so-called strategy extension. The many-sorted strategy s 
is lifted to the generic strategy type 7 using the form s < 7. The extended strat- 
egy will immediately fail when applied to a term of a sort that is different from 
the domain of s. Generic strategies are composed in a manner that they recover 
from failure of extended many-sorted ingredients by applying appropriate generic 
defaults or by recursing into the given term. 

Value of typing The common arguments in favour of compile-time as opposed 
to run-time type checking remain valid for strategic term rewriting. Let us reiter- 
ate some of these arguments in our specific setting to justify our contribution of a 
typed rewriting calculus. To start with, the type system of S'^ and the corresponding 
reduction semantics should obviously prevent us from constructing ill-typed terms. 
Consider, for example, the rewrite rule iNC = N ^ succ{N) of type Nat —>■ Nat 
for incrementing naturals in the context of example (I) above. The left-hand side 
of rewrite rule iNC would actually match with all terms of all sorts, but it only 
produces well-typed terms when applied to naturals. A typed calculus prevents us 
from applying a rewrite rule to a term of an inappropriate sort. Admittedly, most 
rewrite rules use pattern matching to destruct the input term. In this case, ill-typed 
terms cannot be produced. Still, a typed calculus prevents us from even attempt- 
ing the application of a rewrite rule to a term of an inappropriate sort. This is very 
valuable because such attempts are likely to represent a design flaw in a strategy. 
Furthermore, a typed calculus should also prevent the programmer from combining 
specific and generic strategies in certain undesirable ways. Consider, for example, 
an asymmetric choice d^-e where a rewrite rule £ is strictly preferred over the 
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identity strategy e, and only if (. fails, the identity strategy e triggers. This choice is 
controlled by success and failure of i.. One could argue that this strategy is generic 
because the identity strategy e is applicable to any term. Actually, we favour two 
other possible interpretations. One option is to refuse this composition altogether 
because we would insist on the types of the branches in a choice to be the same. 
Another option is to favour the many-sorted argument type for the type of the com- 
pound strategy. In fact, strategies should not get generic too easily since we other- 
wise lose the valuable precision of a many-sorted type system. Untyped strategic 
programming suffers from symptoms such that strategies fail in unexpected man- 
ner, or generic defaults apply to easily. This is basically the same problem as for 
untyped programming in Prolog. S'^ addresses all the aforementioned issues, and it 
provides static typing for many-sorted and generic strategies. 



Beyond parametric polymorphism Some strategy combinators are easier to type 
than others. Combinators for sequential composition, signature- specific congruence 
operators and others are easy to type in a many-sorted setting. By contrast, generic 
traversal primitives, e.g., a combinator to apply a strategy s to all immediate sub- 
terms of a given term, are more challenging since standard many-sorted types are 
not applicable, and the well-established concept of parametric polymorphism is in- 
sufficient to model the required kind of genericity. Let us consider the type schemes 
underlying the two different forms of generic traversal: 

• TP = Va. a — > a (i.e., type-preserving traversal) 

• TU(r) = Va. a — >^ r (i.e., type-unifying traversal) 

In the schemes, we point out that a is a universally quantified type variable. It is 
easy to see that these schemes are appropriate. A type-preserving traversal pro- 
cesses terms of any sort (i.e., a), and returns terms of the same sort (i.e., a); simi- 
larly for the type-unifying case. In fact, S'^ does not enable us to inhabit somewhat 
arbitrary type schemes. The above two schemes are the only schemes which can be 
inhabited with the traversal combinators of S'^. This is also the reason that we do 
not favour type schemes to represent types of generic strategies in the first place, 
but we rather employ the designated constants TP and TU(r). If we read the above 
type schemes in the sense of parametric polymorphism JRey83| , |Wad89| ], we can 



only inhabit them in a trivial way. The first scheme can only be inhabited by the 
identity function. The second scheme can only be inhabited by a constant function 
returning some fixed value of type r. Generic traversal goes beyond parametric 
polymorphism for two reasons. Firstly, traversal strategies can observe the struc- 
ture of terms, that is, they can descend into terms of arbitrary sorts, test for leafs 
and compound terms, count the number of immediate subterms, and others. Sec- 
ondly, traversal strategies usually exhibit non-uniform behaviour, that is, there are 
different branches for certain distinguished sorts in a traversal. Although strategies 
are statically typed in S'^, the latter property implies that the reduction semantics of 
strategies is type-dependent. 
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Structure of the paper In Section 2, we provide a gentle introduction to the sub- 
ject of strategic programming, and to the rewriting calculus S'^. Examples of traver- 
sal strategies are given. The design of the type system is motivated. As an aside, 
we use the term "type" for types of variables, constant symbols, function symbols, 
terms, strategies, and combinators. We also use the term "sort" in the many-sorted 
sense if it is more suggestive. In Section 3, we start the formal definition of S'^ with 
its many-sorted core. In this phase, we cannot yet cover the traversal primitives. A 
minor contribution is here that we show in detail how to cope with type-changing 
rewrite rules. In Section 4, we provide a type system for generic strategies. The two 
aforementioned schemes of type preservation and type unification are covered. A 
few supplementary issues to complement S'^ are addressed in Section 5. Implemen- 
tation issues and related work are discussed in Section 6 and Section 7. The paper 
is concluded in Section 8. 



Objective An important meta-goal of the present paper is to develop a simple 
and self-contained model of typeful generic programming in the sense of generic 
traversal of many-sorted terms. To this end, we basically resort to a first-order set- 
ting of term rewriting. We want to clearly identify the necessary machinery to ac- 
complish generic traversal in such a simple setting. We also want to enable a simple 
implementation of the intriguing concept of typed generic traversal. The S'^ expres- 
siveness is developed in a stepwise manner. In the course of the paper, we show 
that our type system is sensible from a strategic programmer's point of view. We 
contend that the type system of S'^ disciplines strategic programs in a useful and 
not too restrictive manner. 
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2 Rationale 



We set up a rewriting calculus S'^ inspired by ELAN [ |BKK+98| , |BKKR01| ] and sys- 
tem S [ |VB98| ] . Some basic knowledge of strategic rewriting is a helpful background 
for the present paper (cf. [ ]BKK96| , |VB98| , |CK99| ]). First, we give an overview on 
the primitive strategy combinators of S'^. Then, we illustrate how to define new 
combinators by means of strategy definitions. Afterwards, we pay special attention 
to generic traversal, that is, we explain the meaning of the traversal primitives, and 
we illustrate their expressiveness. In the last part of the section, we sketch the type 
system of 5";!^. The subsequent sections 3-5 provide a formal definition of S'^. 



2.1 Primitive combinators 



In an abstract sense, a term rewriting strategy is a partial mapping from a term to 
a term, or to a set of terms. In an extreme case, a strategy performs normalisation, 
that is, it maps a term to a normal form. We use s and t, possibly subscripted or 
primed, to range over strategy expressions, or terms, respectively. The application 
of a strategy s to a term t is denoted by s @ t. The result r of strategy application is 
called a reduct. It is either a term or "|" to denote failure. The primitive combina- 
tors of the rewriting calculus S'^ are shown in Figure 2. Note that we use the term 
"combinator" for all kinds of operators on strategies, even for constant strategies 
like e and 5 in Figure 2. 



Rewrite rules as strategies There is a form of strategy U U for first-order, 
one-step rules to be applied at the top of the term. The idea is that if the given 
term matches the left-hand side ti, then the input is rewritten to the right-hand side 
tr with the variables in bound according to the match. Otherwise, the rewrite 
rule considered as a strategy fails. We adopt some common restrictions for rewrite 
rules. The left-hand side ti determines the bound variables. (Free) variables on the 
right-hand U side also occur in ti. 



Basic combinators Besides rule formation, there are standard primitives for the 
identity strategy (e), the failure strategy (5), sequential composition (■; ■), non- 
deterministic choice (■ + and negation by failure (-i ■)• Non-deterministic choice 
means that there is no prescribed order in which the two argument strategies are 
considered. Negation by failure means that -i s fails if and only if s succeeds. 
In case of success of -i s, the input term is simply preserved. In addition to non- 
deterministic choice, we should also allow for asymmetric choice, namely left- vs. 
right-biased choice. We assume the following syntactic sugar: 
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t t 


(Rewrite rule) 


e 


(Identity) 


5 


(Failure) 


s; s 


(Sequential composition) 


s + s 


(Non-deterministic choice) 


-1 s 


(Negation by failure) 


c 


(Congruence for constant symbol) 


f{s,... 


, s) (Congruence for function symbol) 




(Apply strategy to all children) 


o(.) 


(Apply strategy to one child) 




(Reduce all children) 




(Select one child) 


± 


(Build empty tuple, i.e., ()) 


s W s 


(Apply two strategies to input) 


s <7 


(Extend many-sorted strategy) 



Fig. 2. Primitives of S' 



Si-^ S2 = Si + (-iSi;S2) 
Si^ S2 = S2^- Si 

That is, in si <+- S2, the left argument has higher priority than the right one. S2 will 
only be applied if si fails. From an operational perspective, it would very well make 
sense to consider asymmetric choice as a primitive since the above reconstruction 
suggests the repeated attempt to perform the preferred strategy. We do not include 
asymmetric choice as a primitive because we want to keep the calculus S'^ as simple 
as possible. 

Congruences Recall that rewrite rules when considered as strategies are applied 
at the top of a term. From here on, we use the term "child" to denote an immedi- 
ate subterm of a term, i.e., one of the ti in a term of the form /(ti, . . . , The 
congruence strategy /(si, ■ ■ ■ , Sn) provides a convenient way to apply strategies 
to the children of a term with / as outermost symbol. More precisely, the argu- 
ment strategies si, . . . , s„ are applied to the parameters ti, . . . , t„ of a term of the 
form /(ti, . . . , t„). If all these strategy applications deliver proper term reducts t[, 
...,t'^, then the term f{t'^, . . . , t^) is constructed, i.e., the outermost function sym- 
bol is preserved. If any child cannot be processed successfully, or if the outermost 
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function symbol of the input tenn is different from /, then the strategy fails. The 
congruence c for a constant c can be regarded as a test for the constant c. One might 
consider congruences as syntactic sugar for rewrite rules which apply strategies to 
subterms based on where-clauses as introduced later. We treat congruences as prim- 
itive combinators because this is helpful for our presentation: the generalisation of 
congruences ultimately leads to the notion of a generic traversal combinator. 



Notational conventions Slanted type style is used for constant symbols, func- 
tion symbols, and sorts. The former start in lower case, the latter in upper case. 
Small Caps type style is used for names of strategies. Variables in term patterns 

are potentially subscripted letters in upper case. We use some common notation to 
declare constant and function symbols such as fork : Tree x Tree Tree. Here, 
"x" denotes the Cartesian product construction for the parameters of a function 
symbol. 

Example 1 We can already illustrate a bit of strategic rewriting with the combina- 
tors that we have explained so far Let us consider the following problem. We want 
to flip the top-level subtrees in a binary tree with naturals at the leafs. We assume 
the following symbols to construct such trees: 

zero : Nat 
succ : Nat Nat 
leaf : Nat — > Tree 
fork : Tree x Tree Tree 

N and T optionally subscripted or primed are used as variables of sort Nat and 
Tree, respectively. We can specify the problem of flipping top-level subtrees with a 
standard rewrite system. We need to employ an auxiliary function symbol ffiptop in 
order to operate at the top-level. 

fliptop{fork{Ti,T2)) ^ fork{T2,Ti) 

Note that there is no rewrite rule which eliminates Siptop when applied to a leaf. 
We could favour the invention of an error tree for that purpose. Now, let us consider 
a strategy FlipTop to flip top-level subtrees: 

FlipTop = fork{Ti,T2) fork{T2,Ti) 

That is, we define a strategy, in fact, a rewrite rule FlipTop which rewrites a fork 
tree by flipping the subtrees. Note that this rule is non-terminating when considered 
as a standard rewrite system. However, when considered as strategy, the rewrite 
rule is only applied at the top of the input term, and application is not iterated in 
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any way. Note also that an application of the strategy FlipTop to a leaf will simply 
fail. There is no need to invent an error element. If we want FlipTop to succeed 
on a leaf, we can define the following variant of FlipTop. We show two equivalent 
definitions: 

FlipTop' = FlipTop ^ e 

= FlipTop + leaf{e) 

In the first formulation, we employ left-biased choice and the identity e to recover 
from failure if FlipTop is not applicable. In the second formulation, we use a case 
discrimination such that FlipTop handles the constructor fork, and the construc- 
tor leaf is covered by a separate congruence for leaf. 

Generic traversal combinators Congruences can be used for type- specific traver- 
sal. Generic traversal is supported by designated S'^ combinators □(•), O(-), O (■)> 
and tt(-)- These traversal combinators have with congruences in common that they 
operate on the children of a term. Since traversal combinators have to cope with any 
number of children, one might view them as list-processing functions. The strategy 
□ (s) applies the argument strategy s to all children of the given term. The strategy 
0(s) applies the argument strategy s to exactly one child of the given term. The se- 
lection of the child is non-deterministic but constrained by the success-and-failure 
behaviour of s. The strategies □(s) and are meant to be type-preserving since 
they preserve the outermost function symbol. The remaining traversal combinators 
deal with type-unifying traversal. The strategy (s) reduces all children. Here s 
is used to process the children, and So is used for the pairwise composition of the 
intermediate results. We will later discuss the utility of different orders for process- 
ing children. The strategy ^(s) processes one child via s. The selection of the child 
is non-deterministic but constrained by the success-and-failure behaviour of s as in 
the case of the type-preserving 0{s). 

There are two trivial combinators which are needed for a typeful treatment of type- 
unifying strategies. They do not perform traversal but they are helpers. The strategy 
A. builds the empty tuple (). The strategy A. allows us to discard in a sense the 
current term of whatever sort, and replace it by the trivial term () . This is useful if 
we want to migrate to the fixed and content- free empty tuple type. Such a migration 
is sometimes needed if we are not interested in the precise type of the term at hand, 
e.g., if want to encode constant strategies, that is, strategies which return a fixed 
term. The strategy si || S2 applies the two strategies si and S2 to the input term, 
and forms a pair from the results. This is a fundamental form of decomposition 
relevant for type-unifying traversal. Obviously, one can nest the application of the 
combinator • || if more than two strategies should be applied to the input term. 

The last combinator • < • in Figure 2 serves for lifting a many-sorted strategy such 
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Try(z/) = 1/ •H- e (Apply v if possible, succeed otherwise) 

Repeat(i/) = Try(j^; Repeat(z^)) (Apply u as often as possible) 
Chi(i/, vt, Uf) = {u; vt) ^ (A; Uf) ("Characteristic function") 

Fig. 3. Reusable strategy definitions 

as a rewrite rule to the generic level. We postpone discussing this combinator until 
Section 2.4 when typed strategic programming is discussed. 

2.2 Strategy definitions 

New strategy combinators can be defined by means of the abstraction mecha- 
nism for strategy definition. We use v, possibly subscripted, for formal strategy 
parameters in strategy definitions. A strategy definition (/^(z/i, . . . , Vn) = s intro- 
duces an n-ary combinator cp. Strategy definitions can be recursive. When we en- 
counter an application (^(si, . . . , s„) of cp, then we replace it by the instantiation 
s{z/i si, . . . , z/„ 1-^ Sn} of the body s of the definition of ip. This leads to a suffi- 
ciently lazy style of unfolding strategy definitions. 

In Figure 3, three simple strategy definitions are shown. These definitions embody 
idioms which are useful in strategic programming. Firstly, Try(s) denotes the id- 
iom to try s but to succeed via e if s fails. Secondly, REPEAT (s) denotes exhaus- 
tive iteration in the sense that s is performed as many times as possible. Thirdly, 
Chi(s, St, Sf) is intended to map success and failure of s to "constants" St and sj, 
respectively. To this end, s is supposed to compute () (if it succeeds), while st and 
s f map the "content-free" () to some term. The helper A. is used in the right branch 
to prepare for the application of the constant strategy Sf. 

Example 2 Recall Example 1 where we defined a strategy FlipTop for flipping 
top-level subtrees. Let us define a strategy FlipAll which flips subtrees at all lev- 
els: 

FlipAll = TRY(FLipTop;fork(FLipALL, FlipAll)) 

Note how the congruence for fork trees is used to apply FlipAll to the subtrees of 
a fork tree. 

Polyadic strategies Many strategies need to operate on several terms. Consider, 
for example, a strategy for addition. It is supposed to take two naturals. There are 
several ways to accomplish strategies with multiple term arguments. Firstly, the 
programmer could be required to define function symbols for grouping. Although 
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this is a very simple approach to deal with polyadic strategies, it is rather inconve- 
nient for the programmer because (s)he has to invent designated function symbols. 
Secondly, we could introduce a special notation to allow a kind of polyadic strategy 
application with multiple term positions. This will not lead to an attractive simple 
calculus. Thirdly, we could consider curried strategy application. This would im- 
mediately lead to a higher-order calculus. Recall that we want stay in a basically 
first-order setting. Fourthly, polyadic strategies could be based on polymorphic tu- 
ple types. This is the option we choose. There are distinguished constructors for 
tuples. The constant symbol () represents the empty tuple, and a pair is represented 
by (ti, t2). The notions of rewrite rules and congruence strategies are immediately 
applicable to tuples. For simplicity, we do not consider arbitrary polymorphic types 
in S'^, but we restrict ourselves to polymorphic tuples in S'^. 

Example 3 To map a pair of naturals to the first component, the rewrite rule 
(TVi, A^2) — -^1 is appropriate. To flip the top-level subtrees of a pair of fork trees, 
the congruence (FlipTop, FlipTop) is appropriate. 

Example 4 The following confluent and terminating rewrite system deflnes addi- 
tion of naturals in the common manner: 



add : Nat x Nat Nat 

add{N, zero) N 

add{Ni,succ{N2)) succ{add{Ni, N2)) 

That is, add is a function symbol to group two naturals to be added. We rely on a 
normalisation strategy such as innermost to actually perform addition. By contrast, 
we can also deflne a polyadic strategy Add which takes a pair of naturals: 



Dec = succ{N) N 
iNC = ^ succ{N) 
ADD^^^^ = {N,zero) ^ N 
ADDsfep = (e, Dec); Add; Inc 

ADD=ADDf,35e + ADDstep 

For clarity of exposition, we deflned a number of auxiliary strategies. Dec at- 
tempts to decrement a natural. iNC increments a natural. Actual addition is per- 
formed according to the scheme of primitive recursion with the helpers ADDj^^^g 
and Add giQp for the base and the step case. Both cases are mutually exclusive. The 
base case is applicable if the second natural is a zero. The step case is applicable 
if the second natural is a non-zero value since Dec will otherwise fail. Notice how 
a congruence for pairs is employed in the step case. 
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Where-clauses For convenience, we generalise the concept of rewrite rules as 
follows. A rewrite rule is of the form t ^ b where t is the term of the left-hand side 
as before, and b is the right-hand side body of the rule. In the simplest case, a body 
6 is a term t' as before. However, a body can also involve where-clauses. Then b is 
of the following form: 

b' where x = s@t' 

The meaning of such a body with a where-clause is that the term reduct which 
results from the strategy application s @ t' is bound to x for the evaluation of the 
remaining body b'. For simplicity, we assume a linear binding discipline, that is, x 
is not bound elsewhere in the rule. 

Example 5 We illustrate the utility of where-clauses by a concise reconstruction 
of the strategy Add from Example 4: 

Add = {N, zero) 

+ {Ni, succ{N2)) succ( A^s) where = Add @ {Ni, N2) 

The strategy takes roughly the form of an eager functional program with pattern- 
match case a la SML. 



2.3 Generic traversal 

Let us discuss the core asset of S!^, namely its combinators for generic traversal in 
some detail. To prepare the explanation of the corresponding primitives, we start 
with a discussion of how to encode traversal in standard rewriting. By "standard 
rewriting", we mean many- sorted, first-order rewriting based on a fixed normalisa- 
tion strategy. We derive the strategic style from this encoding. Afterwards, we will 
define a number of reusable schemes for generic traversal in terms of the S'^ primi- 
tives. Ultimately, we will provide the encodings for the traversal problems posed in 
the introduction. 



Traversal functions Suppose we want to traverse a term of a certain sort. In the 

course of traversing into the term, we need to process the subterms of it at maybe 
all levels. In general, these subterms are of different sorts. If we want to encode 
traversal in standard rewriting, we basically need an auxiliary function symbol for 
each traversed sort to map it to the corresponding result type. Usually, one has to 
define one rewrite rule per constructor in the signature at hand. 



14 



Example 6 Let us define a traversal to count leafs in a tree. Note that a function 
from trees to naturals is obviously type-changing. Consider the following rewrite 
rule: 

Count jg^^ = leaf{N) succ{zero) 



This rule directly models the essence of counting leafs, namely it says that a leaf is 
mapped to 1, i.e., succ{zero). In standard rewriting, we cannot employ the above 
rewrite rule since it is type-changing. Instead, we have to organise a traversal with 
rewrite rules for an auxiliary function symbol count- 
count : Tree Nat 
count(leaf(N)) succ{zero) 
count{fork{Ti,T2)) add{count{Ti) , count{T2)) 



The first rewrite rule restates COUNT j^^^m a type-preserving manner The second 
rewrite rule is only there to traverse into fork trees. In this manner, we can cope with 
arbitrarily nested fork trees, and we will ultimately reach the leafs that have to be 
counted. Note that if we needed to traverse terms which involve other constructors, 
then designated rewrite rules had to be provided along the schema used in the 
second rewrite rule for fork above. That is, although we are only interested in leafs, 
we still have to skip all other constructors to reach leafs. To be precise, we have to 
perform addition all over the place to compute the total number of leafs from the 
number of leafs in subterms. 



Traversal strategies Traversal based on such auxiliary function symbols and 
rewrite rules gets very cumbersome when larger signatures, that is, more construc- 
tors, are considered. This problem has been clearly articulated in [ |BSV97[ , |VBT98| , 



ILVKOq , pSVOq , IBKVOII , IVlsOTl ]. An application domain which deals with large 



signatures is program transformation. Signatures correspond here to language syn- 
taxes. The aforementioned papers clearly illustrate the inappropriateness of the 
manual encoding of traversal functions for non-trivial program transformation sys- 
tems. The generic traversal facet of strategic programming solves this problem in 
the most general way. In strategic rewriting, we do not employ auxiliary function 
symbols and rewrite rules to encode traversal, but we rely on expressiveness to pro- 
cess the children of a term in a uniform manner. In fact, traversal combinators allow 
us to process children regardless of the outermost constructor and the type of the 
term at hand. 

Example 7 Let us attempt to rephrase Example 6 in strategic style. We do not want 
to employ auxiliary function symbols, but we want to employ the type-changing 
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rewrite rule COUNT j^^f for handling the terms of interest. In our first attempt, we 
do not yet employ traversal combinators. We define a strategy COUNT as follows: 



UNWRAPfo^j, = forkiTi , T2) ^ (Ti , T2) 
Count jg3^= leaf{N) succ{zero) 

COUNT^jj^j^ = UNWRAP^jj^j^; (COUNT, COUNT); ADD 

Count = Count Count^^^^^ 

The helper CoUNT^^^j^ specifies how to count the leafs of a proper fork tree. That 
is, we first turn the fork tree into a pair of its subtrees via Unwrap fQ^-j^, then 
we perform counting for the subtrees by means of a type-changing congruence on 
pairs, and finally the resulting pair is fed to the strategy for addition. Note that the 
recursive formulation of COUNT allows us to traverse into arbitrarily nested fork 
trees. In order to obtain a more generic version of COUNT, we can use a traversal 
combinator to abstract from the concrete constructor in CoUNT^^^^j,. Here is a 
variant of Count which can cope with any constructor with one or more children: 



Count iQ^f= leaf (N) succ{zero) 

Count any = 0^°° (Count) 

Count = Count jg^^^ CouNTany 

That is, we use the combinator O (') reduce children accordingly. Note that 
left-biased choice is needed in the new definition of Count to make sure that 
Count jgg^ is applied whenever possible, and we only descend into the term for 
non-leaf trees. We should finally mention that the strategy COUNT is not yet fully 
faithful regarding typing because we pass the many-sorted strategy Count to 
O (■) whereas the argument for processing the children is intentionally generic. 



Traversal schemes In Figure 4 and Figure 5, we derive some combinators for 
generic traversal. Most of the combinators should actually be regarded as reusable 
definitions of traversal schemes. The definitions immediately illustrate the poten- 
tial of the generic traversal combinators. Several of the definitions from the type- 
preserving group are adopted from [ |VB98y . We postpone discussing typing issues 
for a minute. Let us read a few of the given definitions. The strategy TD (s) applies s 
to each node in top-down manner. This is expressed by sequential composition such 
that s is first applied to the current node, and then we recurse into the children. It is 
easy to see that if s fails for any node, the traversal fails entirely. A similar derived 
combinator is StopTD. However, left-biased choice instead of sequential compo- 
sition is used to transfer control to the recursive part. Thus, if the strategy succeeds 
for the node at hand, the children will not be processed anymore. Another insight- 
ful, intentionally type-preserving example is Innermost which directly models 
the innermost normalisation strategy known from standard rewriting. The first three 
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Con 


= m 


(Test for a constant) 


Fun 


= 0{e) 


(Test for a compound term) 


0*(i/) 


= □(Try(i/)) 


(Process several children) 


a+(zy) 


= ^□(^zy);0*(i/) 


(Process at least one child) 


TD{u) 


= i/;n(TD(i/)) 


(Top-down traversal) 


BU(z/) 


= □(BU(i^));i/ 


(Bottom-up traversal) 


ONCETD(zy) 


= i/^0(OnceTD(i/)) 


(Process one node in top-down manner) 


OnceBU(i^) 


= i/-KO(OnceBU(i/)) 


(Process one node in bottom-up manner) 


Innermost(i/) 


= Repeat(OnceBU(i/)) 


(Innermost evaluation strategy) 


StopTD(z/) 


= i/^n(STOPTD(zy)) 


(Top-down traversal with "cut") 



Fig. 4. Definitions of type-preserving combinators 



Any(z/) = Z/ + Jj(ANY(z/)) 

TM(jy) = l/^Jj(TM(l/)) 

Bm(i/) = i/-Kjj(BM(i/)) 

CF{u, iJ^,Uo) = (Con;A;i/„) + (Fun;0''°M) 

CRUSH(z^, Vu, Vo) = II CF(CRUSH(i/, Vu, Vo), Vu, Uo)); 



STOPCRUSH(z^, Z/„, Z^o) = z/^CF(STOPCRUSH(z^, t'„,i/o),f„,z/o) 
Fig. 5. Definitions of type-unifying combinators 



type-unifying combinators Any, Tm, and Bm deal with the selection of a subterm. 
They all have in common that they resort to the selection combinator jj(-) to de- 
termine a suitable child. They differ in the sense that they perform search either 
non-deterministically, or in top-down manner, or in bottom-up manner. One might 
wonder whether it is sensible to vary the horizontal order as well. We will discuss 
this issue later. The combinator CF complements O (") to ^l^o cope with a con- 
stant. To this end, there is an additional parameter Vu for the "neutral element" to 
be applied when a constant is present. The combinators CRUSH and StopCrush 
model deep reduction based on the same kind of monoid-like argument strategies 
as CF. As an aside, the term crushing has been coined in the related context of 
polytypic programming [ |Mee96| ] . The combinator CRUSH evaluates each node in 
the tree, and hence, it needs to succeed for each node. The reduction of the cur- 
rent node and the recursion into the children is done in parallel based on • || •. The 
corresponding pair of intermediate results is reduced with the binary monoid oper- 
ation. StopCrush is similar to StopTD in the sense that the current node is first 
evaluated, and only if evaluation fails, then we recurse into the children. 
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Combinators on Booleans 
False = () ^ false (Build "false") 

True = () ^ true (Build "true") 



Combinators on naturals 

Nat = zero + succ{e) (Test by congruences) 

Zero = () ^ zero (Build "0") 

One = {) ^ succ{zero) (Build "1") 

iNC = N ^ succ{N) (Increment) 

Add = ... (Addition; see Example 4) 



Combinators on lists of naturals 
Nil = ^ nil (Build "nil") 

Singleton = N ^ cons{N, nil) (Construct a singleton list) 

Append = ... (Append two lists; definition postponed) 



Actual encodings of (I)-(IV) 

(I) = StopTD(Nat;1nc) 

(II) = OnceBU(<7(P) ^ g'{P)) 

(III) = Chi(Any(Nat; A), True, False) 

(IV) = StopCrush(Nat; Singleton, Nil, Append) 

(V) = CRUSH(CHl(c/(e); A, ONE, ZERO), ZERO, ADD) 

Fig. 6. Untyped encodings for traversal problems from Figure 1 



Example 8 Let us solve the problems (I)-(V) illustrated in Figure 1 in the introduc- 
tion of the paper In Figure 6, we first define some auxiliary strategies on naturals, 
Booleans, and lists of naturals, and then, the ultimate traversals (I)-(V) are defined 
in terms of the combinators from Figure 3-Figure 5. Note that the encodings are not 
yet fully faithful regarding typing. We will later revise these encodings accordingly. 
Let us explain the strategies in detail. 

(I) We are supposed to increment all naturals. The combinator StopTD is em- 
ployed to descend into the given term as long as we do not find a natural recog- 
nised via Nat. When we encounter a natural in top-down manner, we apply 
the rule iNC for incrementing naturals. Note that we must not further descend 
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into the term. In fact, if we used TD instead of StopTD, we describe a non- 
terminating strategy. Also note that a bottom-up traversal is not an option either. 
If we used BU instead of StopTD, we model the replacement of a natural N by 

2Ar + 1. 

(II) We want to replace terms of the form g{P) by g'{P)- As we explained in the 
introduction, the replacement must not be done exhaustively. We only want to 
perform one replacement where the corresponding redex should be identified in 
bottom-up manner These requirements are met by the combinator OnceBU. 

(III) We want to find out if naturals occur in the term. The result should be en- 
coded as a Boolean; hence, the two branches TRUE and FALSE in Cm. We look 
for naturals again via the auxiliary strategy NAT. The kind of deep matching we 
need is provided by the combinator Any which non-deterministically looks for 
a child where NAT succeeds. Nat is followed by A to express that we are not 
looking for actual naturals but only for the property if there are naturals at all. 
The application of Cm turns success and failure into a Boolean. 

(IV) To collect all naturals in a term, we need to perform a kind of deep reduction. 
Here, it is important that reduction with cut (say, StopCrush) is used because 
a term representing a non-zero natural N "hosts " the naturals — 1 , . . . , 
due to the representation of naturals via the constructors succ and zero. These 
hosted naturals should not be collected. Recall that crushing uses monoid-like 
arguments. In this example. Append is the associative operation of the monoid, 
and the strategy NIL to build the empty list represents the unit of APPEND. 

(V) Finally, we want to count all occurrences of g. In order to locate these oc- 
currences, we use the congruence g{e). In this example, it is important that we 
perform crushing exhaustively, i.e., without cut, since terms rooted by g might 
indeed host further occurrences of g. We assume that all occurrences of g have 
to be counted. 

Note the genericity of the defined strategies (I)-(V). They can be appUed to any 
term. Of course, the strategies are somewhat specific because they refer to some 
concrete constant or function symbols, namely true, false, zero, succ, g, and g'. 

2.4 Typed strategies 

Let us now motivate the typeful model of strategic programming underlying S'^. 
The ultimate challenge is to assign types to generic traversal strategies like TD, 
StopTD, or Crush. Recall our objective for S'^ to stay in a basically first-order 
many-sorted term rewriting setting. The type system we envisage should be easy to 
define and implement. 



Many-sorted types Let us start with a basic, many-sorted fragment of S'^ without 
support for generic traversal. We use r and tt, possibly subscripted or primed, to 



19 



range over term types or strategy types, respectively. Term types are sorts and tuple 
types. We use (ti, to denote the product type for pairs {ti, 12). The type of the 
empty tuple () is simply denoted as (). A strategy type tt is a first-order function 
type, that is, tt is of the form r — > r'. Here, r is the type of the input term, and r' 
is the type of the term reduct. We also use the terms domain and co-domain for r 
or r', respectively. The type declaration for a strategy combinator tp which does not 
take any strategy arguments is of the form Lp : vr. The type declaration for a strategy 
combinator ip with n > 1 arguments is represented in the following format: 

(y5 : TTi X • • • X 7r„ ^ TTo 

Here, tti, . . . , 7r„ denote the strategy types for the argument strategies, and ttq de- 
notes the strategy type of an application of </?. All the tTj are again of the form 
Ti t[. Consequently, strategy combinators correspond to second-order functions 
on terms. This can be checked by counting the level of nesting of arrows "— >" in a 
combinator type. 

Example 9 We show the type of FlipAll /rem Example 2, the type of the congru- 
ence combinator fork{-, ■) for the function symbol fork used in Example 2, and the 
type of Add from Example 4. 

FlipAll : Tree Tree 

fork : {Tree — > Tree) x (Tree — > Tree) {Tree Tree) 
Add : {Nat, Nat) Nat 

Type inference vs. type checking For simplicity, we assume that the types of all 
function and constant symbols, variables, and strategy combinators are explicitly 
declared. This is well in line with standard practice in term rewriting and algebraic 
specification. Declarations for variables, rewriting functions and strategies are com- 
mon in several frameworks for rewriting, e.g., in CASL, ASF+SDF, and ELAN. 
Note however that this assumption is not essential. Inference of types for all sym- 
bols is feasible. In fact, type inference is simple because the special generic types 
of S'^ are basically like constant types, and their inhabitation is explicitly marked 
by the combinator ■ < •. We will eventually add a bit of parametric polymorphism 
to S'^ but since we restrict ourselves to top-level quantification, type inference will 
still be feasible. 

Example 10 To illustrate type declarations, we define a strategy APPEND to ap- 
pend two lists. For simplicity, we do not consider a polymorphic APPEND, but one 
that appends lists of naturals. We declare all the constant and function symbols 
(namely nil and cons), and variables for lists (namely Li, L2, L3) and naturals as 
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list elements (namely N). 

nil : NatList 

cons : Nat x NatList NatList 

Li,L2,L3 : NatList 

N : Nat 

Append : {NatList, NatList) NatList 
Append = {nil, L) ^ L 

+ {cons{N, Li), L2) cons{N, L3) where L3 = Append @ (^1,^2) 



Generic types In order to provide types for generic strategies, we need to ex- 
tend our basically many-sorted type system. To this end, we identify distinguished 
generic types for strategies which are applicable to all sorts. We use 7 to range over 
generic strategy types. There are two generic strategy types. The type TP models 
generic type-preserving strategies. The type TU(r) models type-unifying strategies 
where all types are mapped to r. These two forms correspond to the main character- 
istics of Si^. The types TP and TU(-) can be integrated into an initially many-sorted 
system in a simple manner. 

Example 11 The following types are the intended ones for the illustrative strate- 
gies defined in Figure 6. 

(I), (II) : TP 

(III) : TU (Boolean) 

(IV) : TU (NatList) 

(V) : TU(Nat) 



Parametric polymorphism Generic strategy types capture the kind of generic- 
ity needed for generic traversal while being able to mix uniform and sort-specific 
behaviour. In order to turn 5*:^ in a somewhat complete programming language, we 
also need to enable parametric polymorphism. Consider, for example, the combi- 
nator CRUSH for deep reduction in Figure 5. The result type of reduction should be 
a parameter. The overall scheme of crushing is in fact not dependent on the actual 
unified type. The arguments passed to CRUSH are the only strategies to operate on 
the parametric type for unification. We employ a very simple form of parametric 
polymorphism. Types of strategy combinators may contain type variables which 
are explicitly quantified at the top level [ |Mil78| , |CW85| ]. We use a, possibly sub- 
scripted, for term-type variables. Thus, in general, a type of a strategy combinator 
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is of the following form: 



^ ■ Vai Wam- TTi X • • • X 7r„ ^ TTo 



We assume that any type variable in ttq, . . . , 7r„ is contained in the set {ai, . . . , am}- 
Furthermore, we assume explicit type application, that is, the application of a type- 
parameterised strategy combinator ip involves type application using the following 
form: 



li • • • ) Sn) 



For convenience, an actual implementation of S'^ is likely to support implicit type 
application. Also, a more complete language design would include support for pa- 
rameterised datatypes such as parameterised lists as opposed to lists of naturals 
in Example 10. For brevity, we omit parameterised datatypes in the present paper 
since they are not strictly needed to develop a typeful model of generic traversal, 
and a corresponding extension is routine. Parameterised algebraic datatypes are 
well-understood in the context of algebraic specification and rewriting. The instan- 
tiation of parameterised specifications or modules is typically based on signature 
morphisms as supported, e.g., in CASL PABK+Oip or ELAN 0BKK+98| ]. A more 



appealing approach to support parameterised datatypes would be based on a lan- 
guage design with full support for polymorphic functions and parameterised data 
types as in the functional languages SML and Haskell. 

Example 12 Here are the types for the strategy combinators from Figure 3-Figure 5. 
All traversal schemes which involve a type-unifying facet, need to be parameterised 
by the unified type. 



Try, Repeat : TP ^ TP 

Chi : Va.TU(()) ^ (() a) ^ (() ^ a) ^ TU(a) 

Con, Fun : TP 

O*,. . . ,StopTd : TP ^ TP 

Any,Tm,Bm : Va.TU(a) TU(a) 

CF, Crush, StopCrush : Va.TU(a) x (() ^ a) x {{a, a) a) ^ TU(a) 
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We update all definitions which involve type parameters: 



z/ + tl(ANY[a](z/)) 



ANY[a](z/) 

TM[a](z/) 

Bm[q;](z/) 



CF[a](i/, i/„,z^o) 
CRUSH[a](i/,f„,z^o) 



(CON;A;i.„) + (FuN;0"°W) 
{u II CF[a]{CRVSn[a]{u,Uu,Uo),i^u,i^o));i^, 



■o 



STOPCRUSH[a](z/, z/u,i/o) = z^^CF[q;](STOPCRUSH[q;](i/, z/u,z/o),^'u,z^o) 

Example 13 Let us also give an example of a polymorphic strategy definition 
which does not rely on the generic strategy types TP and TU(-) at the same time. 
Consider the declaration TRY : TP — > TP from Example 12. This type is motivated 
by the use of TRY in the definition of traversal strategies, e.g., in the definition of 
0*(-) in Figure 4. However, the generic type of Try invalidates the application 
of Try in Example 2 where it was used to recover from failure of a many-sorted 
strategy. We resolve this conflict of interests by the introduction of a polymorphic 
combinator Try' for many-sorted strategies, and we illustrate it by a correspond- 
ing revision of Example 2: 

Try' : Va. {a —>■ a) ^ {a ^ a) 

TRY'[a]{u) = i/^e 

FlipAll = Try' [ Tree] (Flip ; fork:(FLipALL , FlipAll ) ) 
Hence, we strictly separate many-sorted vs. generic recovery from failure. 

Strategy extension The remaining problem with generic strategies is the media- 
tion between many-sorted and generic strategy types. If we look back to the simple- 
minded definition of (I) in Figure 6, we see that NAT; iNC is used as an argument 
for StopTD. The argument is of the many-sorted type Nat Nat. However, the 
combinator StopTD should presumably insist on a generic argument because the 
argument strategy is potentially applied to nodes of all possible sorts. Obviously, 
NAT; Inc will fail for all terms other than naturals because Nat performs a type 
check via congruences for the constructors of sort Nat. It turns out that failure of 
Nat; Inc controls the traversal scheme StopTD in an appropriate manner How- 
ever, if the programmer would have forgotten the type guard Nat, the traversal is 
not type-safe anymore. In general, we argue as follows: 
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A programmer has to explicitly turn many- sorted strategies into generic ones. 
The reduction semantics is responsible for the type-safe application of many- 
sorted ingredients in generic contexts. 

To this end, S'^ offers the combinator • < • to turn a many-sorted strategy into a 
generic one. A strategy of the form s <l 7 models the extension of the strategy s 
to be applicable to terms of all sorts. In s <l7, the 7 is a generic type, and the 
strategy s must be of a many-sorted type r — > r'. The type r — > r' of s and the 
generic type 7 must be related in a certain way, namely the type scheme underlying 
7 has to cover the many-sorted type t ^ t'. Strategy extension is performed in the 
most basic way, namely s <\ 7 fails for all terms of sorts which are different from 
the domain r of s. The reduction semantics of s <l 7 (§1 1 is truly type-dependent, 
that is, reduction involves a check to see whether the type of t coincides with the 
domain of s to enable the application of s. One should not confuse this kind of 
explicit type test and the potential of failure with an implicit dynamic type check 
that might lead to program abort. In typed strategic rewriting, strategy extension is 
a programming idiom to create generic strategies. In a sense, failure is the initial 
generic default for an extended strategy. Subsequent application of ■ + ■ and friends 
can be used to establish behaviour other than failure. That is, one can recover from 
failure caused by • < •, and one can resort to a more useful generic default, e.g., e, 
or the recursive branch of a generic traversal. Strategy extension is essential for the 
type-safe application of many-sorted ingredients in the course of a generic traversal. 

Example 14 We revise Example 8 to finally supply the typeful solutions for the 
traversal problems (I)-(V) from the introduction. The following definitions are in 
full compliance with the S'^ type system: 

(I) = StopTD(Inc<TP) 
(II) = OnceBU(c/(P) ^ g'{P) <\JP) 

(III) = CHl[Boo7ean](ANY[()](NAT<TP; A),True,False) 

(IV) = STOPCRUSH[NatList](NAT < TU(Nat); Singleton, Nil, Append) 
(V) = CRUSH[JVat](CHl[Nat](£?(e) <TP; A,One,Zero),Zero,Add) 

The changes concern the inserted applications of-<-, and the actual type parame- 
ters for type-unifying combinators. In the definition of (I), the strategy iNC clearly 
needs to be lifted to TP; similarly for the rewrite rule in (II). Note that the original 
test for naturals is gone in the revision of (I). The mere type of iNC sufficiently re- 
stricts its applicability. In the definition of (III), the strategy NAT is used to check 
for naturals, and it is lifted to TP. The type-unifying facet of (III) is enforced by 
the subsequent application of A., and it is also pointed out by the application of 
Chi. In the definition of (IV), the strategy Nat is used to select naturals, and it 
is lifted to TU(JVaf). The subsequent application of Singleton converts naturals 
to singleton lists of naturals. The extension performed in (V) can be justified by 
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similar arguments as for (III). In both cases, Chi is applied to map the success 
and failure behaviour of a strategy to distinguished constants. 



Static type safety The resulting typed calculus Sl^ obeys a number of conve- 
nient properties. Firstly, S'^ supports statically type-safe strategic programming. 
Secondly, each strategy expression is strictly either many-sorted or generic. Thirdly, 
many-sorted strategies cannot become generic just by accident, say due to the con- 
text in which they are used. Strategies rather become generic via explicit use of 
■ < •. Fourthly, the type-dependent facet of the reduction semantics is completely 
restricted to • <l ■ . The semantics of all other strategy combinators does not involve 
type dependency. There are no implicit dynamic type checks. 



Admittedly, any kind of type-dependent reduction is somewhat non-standard be- 
cause type systems in the tradition of the A-cube are supposed to meet the type- 
erasure property [ |Bar92| , PLRU97| ]. That is, reduction is supposed to lead to the 
same result even if type annotations are removed. An application of the com- 
binator ■ < ■ implies a type inspection at "run time", but this inspection is con- 
cerned with the treatment of different behaviours depending on the actual term 
type. Also, the inspection is requested by the programmer as opposed to an im- 
plicit dynamic type check that is performed providently by a run-time system. Sim- 
ilar expressiveness has also been integrated into other statically typed languages 
(cf. DACPP91I, IACPR92I, [HM951 |CGL95|, pRW95i |CWM99|, |Gle9^). 



3 Many-sorted strategies 



We start the formal definition of S";^. As a warm-up, we discuss many-sorted strate- 
gies. For simplicity, we postpone formalising strategy definitions until Section 5.1. 
First, we will define the reduction semantics of a basic calculus S'^ corresponding 
to an initial untyped fragment of S'^^. The corresponding piece of syntax is shown in 
Figure 7. Then, we develop a simple type system starting with many-sorted type- 
preserving strategies. We will discuss some standard properties of the type system. 
Afterwards, we elaborate the type system to cover type-changing strategies and tu- 
ples for polyadic strategies. We use inference rules, say deduction rules, in the style 
of Natural semantics [ ]Kah87| , Pes88| , Pet94j ] for both the reduction semantics and 
the type system. 



3.1 The basic calculus S'n 



Reduction of strategy applications As for the dynamic semantics of strategies, 
say the reduction semantics, we employ the judgement s @ t r for the reduction 
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Syntax 



c (Constant symbols) 

/, g (Function symbols) 

X (Term variables) 

t ::= c I f{t, ... ,t) \ X (Terms) 

r ::= t I t (Reducts of rewriting) 

s ::= t —y b \ e \ S \ s; s \ s + s \ ^ s \ c \ f{s, . . . ,s) (Strategies) 

b ::= t (Rule bodies) 



Fig. 7. Syntax of the basic calculus S'q 

of strategy applications. Here, r is the reduct that results from the application of 
the strategy s to the term t. Recall that a reduct is either a term t or "|" denoting 
failure (cf. Figure 7). We assume that strategies are only applied to ground terms, 
and then also yield ground terms. The latter assumption is not essential but it is 
well in line with standard rewriting. In Figure 8, we define the reduction semantics 
of strategy application for the initial calculus S'q. The inference rules formalise our 
informal explanations from Section 2.1. The reduction semantics of 5', is a big- 
step semantics, that is, r in s@t^ r models the final result of the execution of the 
strategy s. 



Notational conventions We use the common mix-fix notation for judgements in 
Natural semantics, that is, a judgement basically amounts to a mathematical rela- 
tion over the ingredients such as s, t, and r in the example s@t^r. The remaining 
symbols "@" and only hint at the intended meaning of the judgement. As for 
s@t ^ r,we say that the reduct r is "computed" from the application of s to t. The 
direction of computation is indicated by Deduction rules are tagged so that 
we can refer to them. Deduction rules define, as usual, how to derive valid judge- 
ments from given valid judgements. Hence, semantic evaluation or type inference 
amounts to a proof starting from the axioms in a Natural semantics specification. 
As for the reduction semantics, we use rule tags that contain "+" whenever the 
reduct is known to be a proper term whereas "— " is used for remaining cases with 
failure as the reduct. We also use the terms "positive" vs. "negative" rules. To avoid 
confusion, we should point out that the term "reduction" has two meanings in the 
present paper, namely reduction in the sense of the reduction semantics for strate- 
gies, and reduction in the sense of traversal where the children of a term are reduced 
by monoid-like combinators (recall O ( ))• 
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Reduction of strategy applications 
Positive rules 

36. {9{ti)=tA0{tr)=t') 

ti ^ tr@t"-> t' 



ule+] 



Negative rules 

^e.e{ti) = t 

ti ^ tr@t"^ ] 



s@t^ r 



rule 



[id+] <5@Wt 



fail- 



Si + S2@t-^ t' 
Si+ S2@t-^t' 



Ineg^ 



seq-t 



[choice+.l] 



[choice+.2] 



[cong+.l] 



A 



A Sn@tn^t' 



f{si,...,Sn)@ 
f{tl, . . . ,tn) f{t'i, ... ,4 



[cong+.2] 



s@t-^t' 

Sl@t'-^t* A S2@t*'-> T 
A 52®*-^ T 



Si + S2@ W t 



c®t ^ t 



/(si,...,s„)@ 
3iG {l,...,n}. SiQii-x^T 

/(si,...,Sn)@ 
f{tl,...,tn)^ T 



neg 



[seq .l] 



[seq-.2] 



[choice 



[cong .l] 



[cong .2] 



[cong .3] 



Fig. 8. Reduction semantics for the basic calculus S'q 



Deduction rules The axioms for e and 5 are trivial. Let us read, for example, the 
rules for negation. The application s@t returns t if the application s@t returns 
"t" (cf. [neg+]). If s@t results in a proper term reduct, then ^s@t evaluates to 
"t" (cf. [neg-]). These rules also illustrate why we need to include failure as reduct. 
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Syntax 

b::= - ■ ■ \b where x = s@t 



Evaluation 
of rule bodies 

Positive rules 



s@t^t' A b{x^t'}-^t" 

b where x = s@t'^ t" 
Negative rules 

b where x = s@t ^ 

s@t'^t' A 6{x t'} T 
6 where x = s@t ^ ^ 



b^ r 



[body+.l] 



[body +.2] 



[body-.l] 



[body- .2] 



Reduction 

of strategy applications 
Positive rule 

36. {9{ti) = t A e{b) ^ t') 

ti ^ 6@ W 
Negative rules 

ti T 

39. {e{ti) = t A e{b) T) 
ti 6®*--^ T 



s@t^ r 



[rule+] 



[rule-.l] 



rule-. 2 



Fig. 9. Extension for where-clauses 



Otherwise, a judgement could not query whether a certain strategy application did 
not succeed. Recall that asymmetric choice also depends on this ability. Let us also 
look at the rules for the other combinators. The rule [seq+] directly encodes the idea 

of sequential composition where the intermediate term t* that is obtained via si is 
then further reduced via S2. Sequential composition fails if one of the two ingredi- 
ents si or S2 fails (cf. [seq-.i], [seq-.2]). As for choice, there is one positive rule for 
each operand of the choice (cf. [ choice+.l], [choice+. 2]). Choice allows recovery from 
failure because if one branch of the choice evaluates to "t", the other branch can 
still succeed. Choice fails if both options do not admit success (cf. [choice-]). The 
congruences for constants are trivially defined (cf. [cong+.i], [cong-.i]). The congru- 
ences for function symbols are defined in a schematic manner to cover arbitrary 

aritieS (cf. [cong+.2], [cong-.2], [cong-.a]). 



Where-clauses In Figure 8, rule bodies were assumed to be terms. In Figure 9, an 

extension is supplied to cope with where-clauses as motivated earlier. The seman- 
tics of rewrite rules as covered in Figure 8 is surpassed by the new rules in Figure 9. 
Essentially, we resort to a new judgement for the evaluation of rule bodies. A rule 
body which consists of a term, evaluates trivially to this term (cf. [body+.i]). A rule 
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body of the fomi b where x = s@t is evaluated by first performing the strategy 
application s @ t, and then binding the intermediate term reduct t' (if any) to x in 
the remaining body b (of. [body+.2]). Obviously, a rewrite rule can now fail for two 
reasons, either because of an infeasible match (cf. [ruie- .i]), or due to a failing sub- 
computation in a where-clause (cf. [rule- .2], [body-.i], and [body- .2]). For brevity, we 
will abstract from where-clauses in the formalisation of the type system for S'^. 
As the reduction semantics indicates, where-clause do not pose any challenge for 
formalisation. 

3.2 Type-preserving strategies 

We want to provide a type system for the basic calculus S'q. We first focus on type- 
preserving strategies. We use S^p to denote the resulting calculus. In fact, type- 
changing strategies are not standard in rewriting. So we will consider them in a 
separate step in Section 3.3. In general, the typed calculus 5*:^ is developed in a 
stepwise and modular fashion. 



Type expressions We already sketched the type syntax in Section 2.4. As for 
purely many-sorted strategies, the forms of term and strategy types are trivially 
defined by the following grammar: 

a (Sorts) 
T ::= a (Term types) 

TT ::= T ^ T (Strategy types) 



Contexts In the upcoming type judgements, we use a context parameter F to 
keep track of sorts a, and to map constant symbols c, function symbols / and term 
variables x to types. Initially, we use the following grammar for contexts: 

F ::= I r, F (Contexts as sets) 

I a\c:a\f:ax---xa^a (Signature part) 
I x : T (Term variables) 

We will have to consider richer contexts when we formalise strategy definitions in 
Section 5.1. Let us state the requirements for a well-formed context F. We assume 
that there are different name spaces for the various kinds of symbols and variables. 
Also, we assume that constant symbols, function symbols and variables are not 
associated with different types in F. That is, we do not consider overloading. All 
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sorts used in some type declaration in F also have to be declared themselves in T. 
Finally, when contexts are composed via Fi, F2 we require that the sets of symbols 
and variables in Fi and F2 are disjoint. Note that disjoint union of contexts will not 
be used before Section 5.1. In fact, our contexts are completely static until then. 



Typing judgements The principal judgement of the type system is the type judge- 
ment for strategies. It is of the form F h s : tt, and it holds if the strategy s is of 
strategy type tt in the context F. Here is a complete list of all well-formedness and 
well-typedness judgements: 



• F h r 

• F h TT 

• F ht:r 

• F I iTT ^ tt' 

• F h TTi; 7r2 TT 

• F h s@t:T 

• F h s : TT 



(Well-formedness of term types) 
(Well-formedness of strategy types) 
(Well-typedness of terms) 
(Negatable types) 
(Composable types) 
(Well-typedness of strategy applications) 
(Well-typedness of strategies) 



Typing rules The corresponding deduction rules are shown in Figure 10. The 
present formulation is meant to be very strict regarding type preservation. For some 
of the rules, one might feel tempted to immediately cover type-changing strategies, 
e.g., for the rules [apply] for strategy application or [comp.i] for composable types in 
sequential composition. However, we want to enable type changes in a subsequent 
step. Let us read some inference rules for convenience. Type preservation is pos- 
tulated by the well-formedness judgement for strategy types (cf. [pi.i]). Rule [apply] 
says that a strategy application s@t is well-typed if the strategy s is of type r — > r, 
and the term t is of type r. Obviously, the strategies e and 6 have many types, 
namely any type r ^ r where F h r holds (cf. [id] and [fail]). In turn, compound 
strategies can also have many types. The strategy types for compound strategies 
are regulated by the rules [neg], [seq], [choice], and [cong.2]. The typing rules for nega- 
tion and sequential composition (cf. [neg] and [seq]) refer to auxiliary judgements for 
negatable and composable types. Their definition is straightforward for the initial 
case of many-sorted type-preserving strategies (cf. [negt.i] and [comp.i]). The com- 
pound strategy si -(- S2 for choice is well-typed if both strategies si and S2 are of a 
common type tt. This common type constitutes the type of the choice. 



Properties We use S'^p to denote the composition of S'q defined in Figure 8, and 
the type system from Figure 10. The following theorem is concerned with proper- 
ties of Sl-p. It says that actual strategy types adhere to the scheme of type preserva- 
tion, strategy applications are uniquely typed, and the reduction semantics is prop- 
erly abstracted in the type system. 
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Well-formedness 
of term types 

a G r 



r hr 



r h(7 



[tau.l] 



Well-formedness 
of strategy types 

r hr 
r hr^T 

Well-typedness of terms 
c:a eV 



r h TT 



[pi.i] 



r hi:r 



r hc:o- 



/: (71 X ••• X cr„ ^ (To G r 
AT h ti : (71 
A ... 



AT \- tn- (Tn 



r l-/(ti,...,t„):(7o 



fun 



X : r G r 
r hxir 



Negatable types 



r hr 



r I iTT tt' 



r I — ^r— >r ^ T ^ T 



[negt.l] 



Composable types 



r h TTl ; 7r2 ^ TT 



r hr 



rhr— >r;r— >r'^ r— >r 



[comp.l] 



Well-typedness 

of strategy applications 



V hs@i:r 



r hs:r ^r A r ht:r 
r hs@t:r 

of strategies 

r ht/:r A T ht^rr 

r h ti —>■ tr : T ^ T 

r h r 



[apply] 



r hs:7r 



r herr^r 

r hr 
r \-5:t^t 

r hsiTrATI ^vr-^ tt' 

r h^srvr' 

r h si : TTl A r h S2 : 7i"2 
A r h TTl ; 7r2 tt 
r h Si; S2 : TT 

r hsi:7r A r hs2:7r 

r h Si + S2 JTT 

c : (7 G r 



r h C:(7 — (7 

/ : £71 X • • • X (7„ ^ (70 G r 
AT h si : (7i ^ (7i 
A • • • 



AT h s„ : (7„ ^ (7„ 



r h /(si,...,S„):(7o ^(70 



rule 



fail 



|neg 



Iseq 



choice 



[cong.l] 



[cong.2] 



Fig. 10. Many-sorted type-preserving strategies 
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Theorem 1 The calculus S'^pfor many-sorted type-preserving strategies obeys the 
following properties: 

(1) Actual strategy types adhere to the scheme of type preservation, i.e., 
for all well-formed contexts T, strategies s and term types r, t': 

r \- s IT ^ t' implies r = r'. 

(2) Strategy applications satisfy unicity of typing (UOT, for short), i.e., 

for all well-formed contexts T, strategies s, term types r, r' and terms t: 
r \- s@t:T A r hs@t:r' implies r = r'. 

(3) Reduction of strategy applications satisfies subject reduction, i.e., 

for all well-formed contexts T, strategies s, term types r and terms t, f: 
r hs:r-^T A r ht:r A s@t-^t' implies T ht'ir. 

In the further development of S'^, we will use refinements of these properties to 
prove the formal status of the evolving type system. UOT and subject reduction 
are basic desirable properties of type systems (cf. [ par92| , peu93| , |Sch94j ]). We 



claim UOT for strategy applications but not for strategies themselves because of 
the typing rules for the constant combinators e and 5. UOT for strategy application 
means that the result type of a strategy application is determined by the type of 
the input term. Subject reduction means that if we initiate a reduction of a well- 
typed strategy application, then we can be sure that the resulting term reduct (if 
any) is of the prescribed type. The following proof is very verbose to prepare for 
the elaboration of the proof in the context of generic types. 

Proof 1 (IH abbreviates induction hypothesis in all the upcoming proofs.) 

(1) We show adherence to the scheme of type preservation by induction on s 
in r h s : TT. Base cases.- Type preservation is directly enforced for rewrite 
rules, e, 6, and congruences for constants by the corresponding typing rules 
(cf. [rule], [id], [fail], and [cong.i]j, that is, the type position in the conclusion is 
instantiated according to the type-preserving form of strategy types. Induc- 
tion step.' Type preservation for -< ■ (cf. [neg]j is implied by the rule [negt.i] for 
negatable types. Strictly speaking, we do not need to employ the IH since the 
type-preserving shape of the result type is enforced by [negt.i] regardless of the 
argument type. As for si, S2, the auxiliary judgement for composable types 
enforces type preservation (cf. T h ^ t ^ r in [comp.i]j. Again, 
the IH does not need to be employed. As for si + S2, the result type coincides 
with the argument types, and hence, type preservation is implied by the IH. 
Finally, type preservation for congruences /(si, . . . , s„) is directly enforced 
by the corresponding typing rule (cf. the type position in the conclusion of 

[cong.2]j. 

(2) Let us first point out that UOT obviously holds for terms because the inductive 
definition ofV h t : r enforces a unique type r for t. Here it is essential that 
we ruled out overloading of function and constant symbols, and variables. 
According to the rule [apply], the result type of a strategy application is equal 
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to the type of the input term. Hence, s@t is uniquely typed. 
(3) In the type-preserving setting, subject reduction actually means that the re- 
duction semantics for strategy applications is type-preserving as prescribed 
by the type system. That is, if the reduction of a strategy application s @ t with 
s : T ^ T, t : T yields a proper term reduct t', then t' is also of type r. We show 
this property by induction on s in s@t ^ r while we assume T \- sit ^ r 
and r \- tiT. To this end, it is crucial to maintain that the IH can only be 
employed for a premise Si@ti ^ t[ and a corresponding type Ti, if we can 
prove the following side condition: 

r \- s-.T^T A r \-t:T A ... 
implies T \- Si : Ti —>■ A T \- ti'.Ti 

With the ". .. "we indicate that actual side conditions might involve additional 
requirements. The judgements V \- Si : Ti —>■ Ti and T \- UiTi have to be ap- 
proved by consulting the corresponding typing rules that relate t to ti, and s 
to Si, and by other means. Note there are no proof obligations for deduction 
rules which do not yield a proper term reduct, namely for negative rules. In 
particular, there is no case for S in the sequel, that is, S is type-preserving in 
a degenerated sense. Base cases.' As for rewrite rules, we know that both the 
left-hand side ti and the right-hand side are of type r as prescribed by [rule]. 
The substitution 9 in [ruie+] preserves the type of the right-hand side as implied 
by basic properties of many-sorted unification and substitution. Hence, rule 
application is type-preserving, e preserves the very input term, and hence, it 
is type-preserving. The same holds for congruences for constants. Induction 
step.' Negation is type-preserving because the very input term is preserved as 
for e. Thus, we do not need to employ the IH for s in -i s. In fact, the IH tells 
us here that we do not even attempt to apply s in an ill-typed manner Let us 
consider sequential composition Si; S2 By the rules [seq] and [comp.i], we 
know that the types of si, S2 and Si, S2 coincide, that is, the common type is 
T ^ T. We want to show that t' in Si; S2@t ^ t' is of the same type as t. As Si 
must be of the same type as Si, S2, the IH is enabled for Si@t^ t*. Thereby, 
we know that t* is of type t. Since we also know that S2 must be of the same 
type as Si; S2. ^he IH is enabled for the second premise S2@t* ^ t'. Hence, 
t' is of the same type as t, and sequential composition is type-preserving. As 
for choice, reduction of si + S2@t directly resorts to either Si@t or S2@t 
(cf [choice+.i] and [choice+.2]j. Wc also know that Si, S2 and Si + S2 have to be 
of the same type (cf. [choice]). Hence, the IH is enabled for the reduction of the 
chosen strategy, be it Si or S2. Finally, let us consider congruence strategies 
where /(si, . . . , s„) @ /(ii, • • • , in) reduced to f(t[, . . . ,t'^) while the t[ are 
obtained by the reduction of the Si @ti (cf. [cong.2]j. Let f : ai x ■ ■ ■ x a,, (Tq 
be in T. Then, we know that for a well-typed term f{ti, . . . , tn), the ti must be 
of type ai (cf. [fun] j. We also know that for a well-typed strategy /(si, . . . , 
the Si must be of type ai ^ ai( cf. [cong.2] ). Hence, the IH is enabled for the var- 
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Well-formedness 
of strategy types 

r h r A r h r' 
r hr^r' 



r hTT 



pi.l 



Well-typedness 

of strategy applications 



r \-s@t:T 



r \- s:t^t' a r \-t:T 
r hs@t:r' 



apply] 



Negatable types 



r h r A r h r' 



r I iTT tt' 



r h^r ^r' 



r — > T 



Well-typedness 
of strategies 

[negt.l] r ht/rr A V ht^rr' 

r h tl tr-.T ^ t' 



Composable types 



r h TTl ; 7r2 TT 



rhTArhT*ArhT' 

r I- T ^ r*; r* ^ r' r ^ r' 



[comp.l] 



r hs:7r 



rule 



Fig. 11. Refinement of S[p to enable type-changing strategies 



ious Si@ti^ t[. Then, the type of f{t'i, . . . , t^) is the same as /(ti, . . . , tn)- 

As an aside, the proof of subject reduction is simplified by the fact that possibly 
recursive strategy definitions were omitted. The use of simple induction on s is 
enabled by the strong normalisation of the purely inductive reduction semantics 
for strategy applications. If recursive strategy definitions were included, proof by 
induction on the depth of derivations is needed. The use of static contexts also 
simplifies our proofs. 



3.3 Type-changing strategies 



In standard rewriting, as a consequence of a fixed normalisation strategy, rewrite 
rules are necessarily type-preserving. It does not make sense to repeatedly look for 
a redex in a compound term, and then to apply some type-changing rewrite rule to 
the redex since this would potentially lead to an ill-typed compound term. In strate- 
gic rewriting, it is no longer necessary to insist on type-preserving rewrite rules. 
One can use strategies to apply type-changing rewrite rules or other strategies in a 
disciplined manner making sure that intermediate results are properly combined as 
opposed to the type-changing replacement of a redex in a compound term. 
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Type system update In Figure 1 1, the type system for type-preserving strategies 
is updated to enable type-changing strategies. We use to denote the refinement 
of S[p according to the figure. The refinements amounts to the following adapta- 
tions. We replace rule [pi.i] to characterise potentially type-changing strategies as 
well-formed. We also replace the rule [apply] for strategy application, and the rule 
[rule] to promote type-changing strategies. Furthermore, the auxiliary judgements 
for negatable and composable strategy types have to be generalised accordingly 
(cf. [negt.i] and [comp.i]). The relaxation for composable types is entirely obvious but 
we should comment on the typing rule for negatable types. Negation is said to be 
type-preserving regardless of the argument's type. This is appropriate because the 
only possible term reduct admitted by negation is the input term itself. The argu- 
ment strategy is only tested for failure. Hence, negation by itself is type-preserving 
even if the argument strategy would be type-changing. All the other typing rules 
carry over from S[p. As an aside, we do not generalise the type of 5 to go beyond 
type preservation. In fact, one could say that the result type of 5 is arbitrary since no 
term reduct will be returned anyway. However, such a definition would complicate 
our claim of UOT. 

Theorem 2 The calculus S'^^for potentially type-changing strategies obeys the fol- 
lowing properties: 

(1) Co-domains of strategies are determined by domains, i.e., for all well-formed 
contexts T, strategies s and term types ti, t[, T2, T'2: 

r h s : Ti — >• r{ A r \- s:t2 ^ T2 A implies T\ ^ T2. 

(2) Strategy applications satisfy UOT, i.e., ... (cf. Theorem 1). 

(3) Reduction of strategy applications satisfies subject reduction, i.e., for all well- 
formed contexts T, strategies s, term types t, t' and terms t, t': 

r hs:r^r' A T htir A s@t-^t' implies T h t' : t'. 

The first property is the necessary generalisation of adherence to the scheme of 
type preservation in Theorem 1. We require that the co-domain of a strategy type 
is uniquely determined by its domain. That is, there might be different types for 
a strategy, but once the type of the input term is fixed, the type of the result is 
determined. The second property carries over from Theorem 1. The third property 
needs to be generalised compared to Theorem 1 in order to cover type-changing 
strategies. 

Proof 2 

(1) Note that the property trivially holds for type-preserving strategies. We show 
the property by induction on s in F h s : tt. Base cases." The co-domain of 

a rewrite rule is even uniquely defined regardless of the domain as an impli- 
cation of UOT for terms. The remaining base cases are type-preserving, and 
hence, they are trivial. Induction step.' Negation is trivially covered because 
it is type-preserving. As for sequential composition, the domain ofsi, S2 coin- 
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cides with the domain ofsi, the co-domain of si coincides with the domain of 
S2, and the co-domain ofs2 coincides with the co-domain ofsi \ S2 (cf. [comp.i] j. 
By applying the IH to Si and S2, we obtain that the co-domain ofsi, S2 is tran- 
sitively determined by its domain. As for choice, the property follows from the 
strict coincidence of the types ofsi, S2, and si-\- S2(cf. [choice]) which immedi- 
ately enables the IH. Congruences /(si, . . . , s„) are trivially covered because 
they are type-preserving. 

(2) The simple argument from Proof! regarding the rule [apply] can be generalised 
as follows. The domain of the strategy in s@t needs to coincide with the type 
oft. Since the co-domain ofs is determined by the type oft (cf. (1) above), we 
know that the type of the reduct is uniquely defined. 

(3) We need to elaborate our induction proof for Proof 1 where we argued that 
subject reduction for type-preserving strategies can be proved by showing 
that the reduction semantics is type-preserving, too. As for potentially type- 
changing strategies, we need to show that reduction obeys the strategy types. 
Hence, the side condition for the employment of the IH has to be revised, too. 
That is, the IH can be employed for a premise Si@ti ^ t[ and corresponding 
types Ti and r/, if we can prove the following side condition: 

r hs:r^r' A T htir A ... 
implies T h Sj : ^ r/ A F h t j : Tj 

Base cases; Subject reduction for rewrite rules is implied by basic properties 
of many-sorted unification and substitution. The remaining base cases are 
type-preserving, and hence, they are covered by Proof 1. Induction step; The 
strategy s in ^ s is not necessarily type-preserving anymore but negation by 
itself adheres to type preservation as prescribed by the type system ( cf. [negt.i] j. 
As for sequential composition, we start from the assumptions T h Si; S2 : r ^ 
r' and F \- t:T,we want to show that t' in si, S2@t ^ t' is of type t'. There 
must exist a r* such that F h si : r — > r* and F h S2 : t* — > r' (by [comp.i] 
and [seq] j. In fact, t* is uniquely defined because it is the co-domain of si 
determined by the domain of Sy which coincides with the domain of Si \ S2. 
We apply the IHfor si @ t, and hence, we obtain that the reduction of Si@t 
delivers a term t* of type r*. This enables the IHfor the second operand of 
sequential composition. Hence, we obtain that the reduction ofs2 @ t* delivers 
a term t' of type r' . As for choice, the arguments from Proof I are still valid 
since we did not rely on type preservation. That is, we know that the reduction 
of the choice directly resorts to one of the argument strategies, and the type of 
the choice has the same type as the two argument strategies. Hence, subject 
reduction for choice follows from the IH. Congruences f{si, . . . ,Sn) and the 
involved arguments are type-preserving, and hence, subject reduction carries 
over from Proof 1. 
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Syntax 



T ::=■■■ 101 {ti,T2) 
*::=••• I I (ti,t2) 
s ::=••• 101 (si,S2) 



Well-formedness 
of term types 

r hO 



r hr 



Well-typedness 
of strategies 



r l-s:7r 



[t-.2] r h : 



[cong.3] 



r h n A r h r2 

r h (ri,r2) 

Well-typedness 
of terms 



[tau.3] 



r htlT 



r 1-0:0 [empty-tuple] 



r h ti : n A r h t2 : T2 

r h (ii,i2):(ri,T2) 



pair 



r hsirn 

AT h S2 : r2 r2 



r I- (si, S2) : (n, T2) {Ti,T^) 



[cong.4] 



The reduction semantics of tuple congru- 
ences is defined precisely as for ordinary 
many-sorted constant and function symbols 



Fig. 12. Tuple types, tuples, and tuple congruences 



3.4 Polyadic strategies 



As we motivated in Section 2, we want to employ tuples to describe polyadic strate- 
gies, that is, strategies which process several terms. In principle, the following ex- 
tension for tuples can be composed with both S'fp and S'f^. However, tuples are only 
potent in S^^ with type-changing strategies enabled. 

In Figure 12, we extend the basic calculus Sq with concepts for polyadic strategies 
in a straightforward manner. There are distinguished symbols () for the empty tuple, 
and (•, •) for pairing terms. We use the same symbols for tuple types, tuples, and 
congruences on tuples. The judgements for well-formedness of term types and well- 
typedness of terms are extended accordingly (cf. [tau.2], [tau.s], [empty-tupie], and [pair]). 
We also introduce special typing rules for congruences on tuples (cf. [cong.3] and 
[cong.4]). Note that the typing rules for congruences for ordinary symbols relied on 
a context lookup (cf. [cong.i] and [cong.2] in Figure 10) while this is not the case for 
polymorphic congruences on tuples. Moreover, congruences on pairs can be type- 
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changing (cf. [cong.4]) whereas this is not an option for many-sorted congruences. 
We should point out that tuples are solely intended for argument and result lists 
while constructor terms should be purely many-sorted. This intention is enforced 
because the argument types of ordinary function symbols are still restricted to sorts 
as opposed to tuple types (cf. [fun] in Figure 10). 

Example 15 The strategy Add from Example 4 and the strategy CoVTSn from Ex- 
ample 7 are well-typed as type-changing strategies. 

Add : {Nat, Nat) Nat 
Count : Tree Nat 

As for Add, we rely on tuple types since addition is encoded as a strategy which 
takes a pair of naturals. As for COUNT, the definition from Example 7 involves a 
type-changing congruence on pairs, namely (COUNT, Count). This congruence 
applies Count to the two subtrees of a fork tree independently. 



4 Generic strategies 

In the present section, we extend our basic calculus for many-sorted strategies 
by types and combinators for generic strategies. First, we spell out the reduction 
semantics of type-preserving combinators, and we formalise the corresponding 
generic type TP. Then, the problem of mediation between many-sorted and generic 
strategies is addressed. There are two directions for mediation. When we qualify a 
many-sorted strategy to become generic, then we perform extension. When we in- 
stantiate the type of a generic strategy for a given sort, then we perform restriction. 
Afterwards, we define the type-unifying traversal combinators and the correspond- 
ing generic type (constructor) TU(-). 

4.1 Strategies of type TP 

Combinators In Figure 13, we define the reduction semantics of the generic 
traversal primitives □(■) and O(-) adopted from system S. The rule [aii+.i] says 
that □(s) applied to a constant immediately succeeds because there are no chil- 
dren which have to be processed. The rule [aii+.2] directly encodes what it means 
to apply s to all children of a term /(ti, . . . , t„). Note that the function symbol / 
is preserved in the result. The reduction scheme for 0(s) is similar. The rule [one+] 
says that s is applied to some subterm ti of /(ti, . . . , t„) such that it succeeds for 
this child. The semantics is non-deterministic as for choice of the child. One could 
also think of a different semantics where the children are tried from left to right or 
vice versa until one child is processed successfully. The negative rule [one .1] says 
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Syntax 

s ::=... I 0(5) I 0(s) 

Reduction of strategy applications 



s@t^t' 



Positive rules Negative rules 

a{s)@c'^c [all+.l] 3ie{l,...,n}.s@ti^'\ 

A ■■■ 



n(s)@fih,...,tn)-^ 
3ie{l,...,n}.s@U^t'i 

0{s)@f(ti,...,tn)^ 
f{ti, . . . ,t'^, . . . ,tn) 



all+.2] 





• • , in) T 


0(s)@c^ T 




S@ti 




A ■■■ 




A S@tn 




Ois)@f{ti,. 





[one .1] 



[one .2] 



Fig. 13. Type-preserving traversal combinators 

that <C>(s) applied to a constant fails because there is no child that could be pro- 
cessed by s. The negative rule [one- .2] says that 0(s) fails if s fails for all children 
of /(ti, . . . , tn). Dually, □(s) fails if s fails for some child (cf. [air]). 



The generic type TP In Figure 14, we extend the typing judgements to formalise 
TP, and to employ TP for the relevant combinators. We establish a syntactical 
domain 7 of generic types. We integrate 7 into the grammar for types by stating 
that 7 corresponds to another form of strategy types tt complementing many-sorted 
strategy types. We start the definition of 7 with the generic type TP. We use a 
relation on types to characterise generic types, say the genericity of types. The 
relation denotes the reflexive closure of -<r- By tt -<r tt', we mean that tt' is 
more generic than tt. If we view generic types as type schemes, we can also say that 
the type tt is an instance of the type scheme tt'. Rule [less.i] axiomatises TP. The 
rule says that r — > r is an instance of TP for all well-formed r. This formulation 
indeed suggests to consider TP as the type scheme Va. a — a. We urge the reader 
not to confuse with subtyping. The remaining rules in Figure 14 deal with well- 
typedness of generic strategies. The constant combinators e and 5 are defined to be 
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Syntax 



IT ::= • • • I 7 
7::= TP 



Well-formedness 
of strategy types 

r hTP 

Genericity relation 

r hr 
r ^ r TP 

Negatable types 



V h7 



r h ^7 



TP 



r hTT 



[pi.2] 



Composable types 



V h7 
r h TP;7 7 

Well-typedness 
of strategies 



[less.l] 



r I — ^ 'k' 



[negt.2] 



r h TTl ; 7r2 ^ TT 



|comp.2l 



r hs:7r 



r he:TP 
r h(5:TP 

r h s:TP 
r h 0(5) : TP 

r hs:TP 
r hO(s):TP 

Fig. 14. TP — The type of generic type-preserving strategies 



fail 



generic type-preserving strategies (cf. [id] and [fail]). As for negation, we add another 

rule to the auxiliary judgement F I 1 tt ^ vr' for negatable types. The enabled 

form of negation is concerned with generic strategies. The rule [negt.2] states that 
any strategy of a generic type 7 can be negated. As for sequential composition, we 
also add a rule to the auxiliary judgement r h 7ri;7r2 ^ tt to cover the case that 
a generic type-preserving strategy and another generic strategy are composed (cf. 
[comp.2]). The typing rules for the traversal combinators state simply that □(■) and 
O(-) can be used to derive a strategy of type TP from an argument strategy of type 

TP (cf. [all] and [one]). 



Well-defined generic strategy types In general, we assume that a well-defined 

generic type should admit an instance for every possible term type since a generic 
strategy should be applicable to terms of all sorts. To be precise, there should be 
exactly one instance per term type. It is an essential property that there is only one 
instance per term type. Otherwise, the type of a generic strategy application would 
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be ambiguous. The type TP is obviously well-defined in this sense. 



Separation of many-sorted and generic strategies Note that there are now two 
levels in our type system, that is, there are many-sorted types and generic types. 
The type system strictly separates many-sorted strategies (such as rewrite rules) 

and generic strategies (such as applications of □(■))• Since there are no further 
intermediate levels of genericity, there are only chains of length 1 in the partial 
order :^r- Longer chains will be needed in Section 5.3 when we consider a possible 
sophistication of S'^ to accomplish overloaded strategies. As the type system stands, 
we cannot turn many-sorted strategies into generic ones, nor the other way around. 
Also, strategy application, as it was defined for S'^p and S'^^, only copes with many- 
sorted strategies. The type system should allow us to apply a generic strategy to 
any term. We will now develop the corresponding techniques for strategy extension 
and restriction. 

4.2 Strategy extension 

Now that we have typed generic traversal combinators at our disposal, we also want 
to inhabit the generic type TP. So far, we only have two trivial constants of type 
TP, namely e and 6. We would like to construct generic strategies from rewrite 
rules. We will formalise the corresponding combinator • < • for strategy extension. 
To this end, we also examine other approaches in order to justify the design of • < •. 



Infeasible approaches In the untyped language Stratego, no distinction is made 
between rewrite rules and generic strategies. We might attempt to lift this design to 
a typed level. We study two such approaches. One infeasible approach to the inhab- 
itation of generic strategy types like TP is that the typing requirements for generic 
strategy arguments would be relaxed: whenever we require a generic strategy ar- 
gument, e.g., for s in we also would accept a many-sorted s. This implicit 
approach to the inhabitation of generic types would only be type-safe if extra dy- 
namic type checks are added. Consider, for example, the strategy where s is 
of some many-sorted type r — > r. For the sake of subject reduction (say, type-safe 
strategy application), the semantics of □ (s) had to ensure that every child at hand is 
of type T before it even attempts to apply s to it. If some child is not of type r, □(s) 
must fail. From the programmer's point of view, the approach makes it indeed too 
easy for many-sorted strategies to get accepted in a generic context. The resulting 
applicability failures of many-sorted strategies in generic contexts are not approved 
by the strategic programmer. By contrast: 

We envision a statically type-safe style of strategic programming, where the em- 
ployment of many-sorted strategies in a generic context is approved by the pro- 
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grammer. Moreover, the corresponding calculus should correspond to a conser- 
vative extension of S^p (or S'^^). 

Another infeasible approach to the inhabitation of generic strategy types is to resort 
to a choice combinator (• + ■ or • ^ •) to compose a many-sorted strategy and a 
generic default. We basically end up having the same problem as above. Let us 
attempt to turn a rewrite rule i into a generic strategy using the form i^- s where 
s is some generic strategy, e.g., e or 5. We could assume that the result type of a 
choice corresponds to the least upper bound of the argument types w.r.t. :<r- One 
possible argument to refuse such a style arises from the following simple derivation: 

S'H-^ ^ s + -'s;6 ^ s + 5 ^ s 

That is, we show that 5 is the unit of ■ ^ ■ while assuming that it is the zero of se- 
quential composition. Since the derivation resembles desirable algebraic identities 
of choice, sequential composition and failure that are also met by the formalisa- 
tion of S'^, we should assume that all strategies in the derivation are of the same 
type. This is in conflict with the idea to use ■ ^ ■ or ■ + • to inhabit generic types. 
Furthermore, the approach would also affect the reduction semantics in a way that 
goes beyond a conservative extension. We had to redefine the semantics of ■ + ■ to 
make sure that the argument strategies are applied only if their type and the type of 
the term at hand fits. Finally, a too liberal typing rule for choice makes it easy for a 
strategic programmer to confuse two different idioms: 

• recovery from failure, and 

• the inhabitation of generic types. 

This confusion can lead to unintentionally generic strategies which then succeed 
(cf. • • • -H- e) or fail (cf. • • • -H- ^) in a surprising manner. The avoidance of this 
confusion is among the major advantages that a typed system offers when compared 
to the currently untyped Stratego. 

Inhabitation by extension The combinator • < ■ serves for the explicit extension 
of a many-sorted strategy to become applicable to terms of all sorts. Suppose the 
type of s is r ^ r. Then, of course, s can only be applied to terms of sort r in a 
type-safe manner. It is the very meaning of s < TP @ t to apply s if and only if t is 
of sort r. Otherwise, s < TP @ t fails. Hence, s is extended in a trivial sense, that 
is, to behave like 5 for all sorts different from r. Well-typedness and the reduction 
semantics of the combinator • < • are defined in Figure 15. We should point out a 
paradigm shift, namely that the typing context F is now also part of the reduction 
judgement. That is, the new judgement for the reduction of strategy applications 
takes the form V h s @ t r. In the typing rule [extend], we check if the actual 
type tt' of s in s < TT is an instance of the type vr for the planned extension. In the 
reduction semantics, in rule [extend+], we check if the type r of the term t is covered 
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Syntax 



s ::- 



S < TT 



Well-typedness 
of strategies 

r h s : tt' a tt' tt 
r h s<7r:7r 



r l-s:7r 



extend 



Reduction of strategy applications 

Positive rule 
V V- s-.-k' 

AT h t:r 
A 3r'. r ^ r' tt' 
AT h sOt'-^t' 



r l-s<7r@Wt' 



[extend+] 



r h s@t-^r 



Negative rules 

r hs:7r' 
AT h i:r 
A 3t'. r ^ t' tt' 

AT h ,s 'tt^ / t 
r h s<7r@t'^ t 

r h s : tt' 
AT ht-.T 

A r ^ tt' 
r h s<7r@t'^ t 

Fig. 15. Turning many-sorted strategies into generic ones 



[extend . l] 



[extend .2] 



by the type tt' of s in s <l tt. Clearly, this check made the addition of the typing 
context r necessary. Note that the generic type tt from s < vr does not play any 
role during reduction. The type tt is only relevant in the typing rule for strategy 
extension to point out the result type of strategy extension. 



Type dependency The combinator ■ < • makes it explicit where we want to be- 
come generic. There is no hidden way how many-sorted ingredients may become 
generic — accidentally or otherwise. As the reduction semantics of ■ < ■ clearly points 
out, reduction is truly type-dependent. That is, the reduction of an extended strategy 
depends on the run-time comparison of the types of s and t in s <| tt @ t. We assume 
that all previous rules of the reduction semantics are lifted to the new form of judge- 
ment by propagating V. Otherwise, all rules stay intact, and hence we may claim 
that the incorporation of ■ < ■ corresponds to a conservative extension. One should 
not confuse type-dependent reduction with dynamic type checks. Type dependency 
merely means that a generic strategy admits different behaviours for different sorts. 
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Syntax 



s ::- 



S (> TT 



Well-typedness 
of strategies 

r h s : tt' a tt 71"' 
r h s > TT : TT 



r hs:7r 



restrict 



Reduction 

of strategy applications 

r h s@t^r 
r h s>7r@t^ r 



r I- s®*-^ r 



restrict^ 



Fig. 16. Explicit strategy restriction 



As an aside, in Section 5.2, we will discuss a convenient approach to eliminate the 
typing judgements in the reduction semantics for strategy extension. The basic idea 
is to resort to tagged strategy applications such that types do not need to be de- 
termined at run-time, but a simple tag comparison is sufficient to perform strategy 
extension. 



4.3 Restriction 



So far, we only considered one direction of mediation between many-sorted and 
generic strategy types. We should also refine our type system so that generic strate- 
gies can be easily applied in specific contexts. Actually, there is not just one way to 

accommodate restriction. Compared to extension, restriction is conceptually much 
simpler since restriction is immediately type-safe without further precautions. In 
general, we are used to the idea that a generic entity is used in a specific context, 
e.g., in the sense of parametric polymorphism. 



Explicit restriction We consider a strategy combinator s>n which has no se- 
mantic effect, but at the level of typing it allows us to consider a generic strategy s 
to be of type tt provided it holds tt tt' where n' is the actual type of s. Explicit 
restriction is defined in Figure 16. The combinator for restriction is immediately 
sufficient if we want to apply a generic strategy s to a term t of a certain sort r. If 
we assume, for example, that s is of type TP, then the well-typed strategy applica- 
tion s > r — > r @ t can be employed. Thus, the rule [apply] for strategy applications 
from Figure 10 or the updated rule from Figure 1 1 can be retained without modifi- 
cations. 



Extension and restriction in concert For completeness, let us assume that we 
also can annotate strategies by their types, say by the form s : tt. This is well-typed 
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if s is indeed of type tt. The reduction of s : vr simply resorts to s. Then, in a 
sense, the three forms s > tt (i.e., explicit restriction), s : tt (i.e., type annotation), 
and s < TT (i.e., strategy extension) complement each other as they deal with the 
different ways how a strategy s and a type tt can be related to each other via the 
partial order :<r- The three forms interact with the type system and the reduction 
semantics in the following manner. Type annotations can be removed without any 
effect on well-typedness and semantics. By contrast, a replacement of a restriction 
s > TT by s will result in an ill-typed program, although s is semantically equivalent 
to s [> TT. Finally, a replacement of an extension s < tt by s will not just harm well- 
typedness, but an ultimate application of s is not even necessarily type-safe. 



Inter-mezzo The concepts that we have explained so far are sufficient to assem- 
ble a calculus Sjp which covers generic type-preserving traversal. Generic type- 
preserving strategies could be combined with both S^p and S'^^. For simplicity, we 
have chosen the former as the starting point for Sjp. For convenience, we sum- 
marise all ingredients of Sjp: 

• The basic calculus S'q (cf. Figure 8) 

• Many-sorted type-preserving strategies (cf. Figure 10) 

• Generic traversal primitives □(•) and O(-) (cf. Figure 13) 

• The generic type TP (cf. Figure 14) 

• Strategy extension (cf. Figure 15) 

• Explicit restriction (cf. Figure 16) 

In Theorem 1, and Theorem 2, we started to address properties of the many-sorted 
fragments S^p and S'^^ of S'^. Let us update the theorem for Sjp accordingly. 

Theorem 3 The calculus Sjp obeys the following properties: 

(1) Strategies satisfy UOT, and their types adhere to the scheme of type preser- 
vation, i.e., for all well-formed contexts F, strategy types tt, tt' and strategies 
s: 

(a) r hsiTT A r hsrvr' implies tt = n', and 

(b) r h s : TT implies tt TP. 

(2) Strategy applications satisfy UOT, i.e., ... (cf. Theorem 1). 

(3) Reduction of strategy applications satisfies subject reduction, i.e., for all well- 
formed contexts T, strategies s, terms t, t' , term types r and strategy types tt: 
r h s-.TT A r ht-.T A r^r^rTT A T h s@t^t' implies T \-t':T. 

This theorem is an elaboration of Theorem 1 for many-sorted type-preserving strate- 
gies. The first property is strengthened since we now claim UOT for strategies. This 
becomes possible because the previously "overloaded" combinators e and 6 are now 
of type TP. Further, we need to rephrase what it means that a strategy type adheres 
to the scheme of type preservation. Also, the formulation of subject reduction needs 



45 



to be upgraded to take TP into account. 
Proof 3 

(1) (a) We prove this property by induction on s inV h s : tt. Base cases; UOT 

for rewrite rules is implied by UOT for terms. Congruences meet UOT 
because of the requirement for well-formed contexts. The two base cases 
for e and 5 trivially satisfy UOT by simple inspection of the type position 
in the rules [id] and [fail]. Induction step." UOT for -i s is implied by the IH 
and by the fact that the auxiliary judgement for negatable types encodes a 
function from the argument type to the type of the negated strategy. UOT 
for si \ S2 and Si + S2 is implied by the IH. In both cases, the type of the 
compound strategy coincides with the type of the arguments (cf. [comp.i], 
[comp.2], [seq], [choice]). UOTfor f{si, . . . , Sn) followsfromwcll-formedness 
of contexts. As for, □(s), 0(s), the property can be inferred by inspection 
of the type position in the corresponding typing rules. As for s < tt and 
s > TT, UOT follows from the fact that the specified n directly constitutes 
the type of the extended or restricted strategy, 
(b) We prove this property by induction on s in T h s : tt. We only need to 
cover the cases which were updated or newly introduced in the migration 
from S[p to Sjp. Base cases.' The types of e and 8 are uniquely defined 
as TP, and hence, they trivially adhere to the required scheme. Induction 
step.' As an aside, we hardly have to employ the IH for the compound 
strategies. The type andO{s) is defined as TP. The forms -1 s and 

Si; S2 where type-preserving in S'^^. There are still type-preserving in Sjp 
since the added rules for negatable and composable types only admit TP 
as an additional possible result type (cf. [negt.2] and [comp.2] j. The property 
holds for choice because the arguments are type preserving by the IH, 
and the result type of choice coincides with the type of the arguments 
(cf. [choice]). The type n in s < tt, and hence the type of s <7r itself, must 
coincide with TP since this is the only possible strategy type admitted as 
the right argument of -<r in Sjp (cf. [extend] and [less.i]). Dually, the type n 
in s>7r, and hence the type of s^n itself, must coincide with a type of 
the form t ^ t because this is the only possible form admitted as the left 
argument of ~<r in Sjp (cf. [restrict] and [less.i]). 

(2) The property follows immediately from 

• UOT for terms, 

• UOT for strategies, and 

• the fact that TP is a "well-defined generic type ", that is, fixing the term type 
T processed by a generic strategy, the result type of strategy application is 
determined, in fact, it is r in the case of TP. 

(3) Note that we only deal with type-preserving strategies which allows us to 
adopt Proof 1 to a large extent. Of course, the side condition for the employ- 
ment of the IH has to be revised. That is, the IH can be employed for a premise 
Si@ti t[ and corresponding types and tTj if we can prove the following 
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side condition: 

r hsiTT A r ht-.T A r^r^rTT A ... 
implies F h Sj : tTj A F h : A Tj — > Tj :<r TTj 

Base cases.' Proof 1 is still intact as for rewrite rules and congruences for 
constants since these forms of strategies were completely preserved in S'jp. 
The strategy e is said to be generically type-preserving according to [id] while 
it was "overloaded" before. Reduction of e@t yields t. Hence, reduction of 
e is type-preserving. Induction step.- The property holds for negation because 
[neg+] only admits the input term as proper term reduct. The proof for sequen- 
tial composition can be precisely repeated as in Proof 1 with the only excep- 
tion that we now have to consider two cases according to [comp.i] and [comp.2]. 
In both cases, the type of si, S2 and si, S2 coincide, and the types adhere to 
the scheme of type preservation. This is all what the original proof relied on. 
Proof 1 also remains valid as for choice and congruences. As for the traversal 
combinators, the property follows from the IH, and the fact that the shape of 
the processed term is preserved. The IH is enabled for any s@ti^ t[ because 
the strategy s in and is required to be of type TP, and hence it can 
cope with any term. The interesting case is s <iiT@t where we assume that t is 
of type T. We want to employ the IHfor the premise T \- s@t'^ t' in [extend+]. 
Hence we are obliged to show that the type tc' of s covers t. This obligation 
is precisely captured by the premise 3t'. t — > r' :<r tt' in [extend+]. Thus the 
IH is enabled, and subject reduction holds. As for s[>7i, we directly resort to 
s. The IHfor the reduction of s is trivially implied since t ^ r <t implies 
T ^ T 7^' for TT -<r ti"' (cf [restrict]) by transitivity of^r- 



Implicit restriction While extension required a dedicated combinator for the rea- 
sons we explained earlier, we do not need to insist on explicit restriction. Implicit 
restriction is desirable because otherwise a programmer needs to point out a spe- 
cific type whenever a generic strategy is applied in a many-sorted context. Implicit 
restriction is feasible because restriction has no impact on the reduction semantics 
of a strategy. Let us stress that implicit restriction does not harm type safety in any 
way. In the worst case, implicit restriction might lead to accidentally many-sorted 
strategies. However, such accidents will not go unnoticed. If we attempt to apply 
the intentionally generic strategy in a generic context or to assign a generic type to 
it, then the type system will refuse such attempts. 

Example 16 Consider the strategy Nat which was defined in Figure 6. It involves 
a congruence succ{e), where e is supposed to be applied to a natural. In Sjp, we 
have to rephrase the congruence as succ{e > Nat). In a calculus with implicit re- 
striction, succ(e) can be retained. 
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Composable types 



TTi ; 7r2 vr 



r h r A r h r' 



r I- r ^ t';TP T -> r' 

r h r A r h r' 
r h TP; r ^ r' T ^ r' 



Icomp.Sl 



[comp.4] 



Well-typedness of 
strategy applications 



r h s : vr A r h t : r 
A 3r'. r — >• r' TT 
r hs@t:r' 



[apply] 



choice 



Well-typedness 

of strategies F h s : tt 

r h si : TTi 
AT h S2 : 7r2 

A r h TTl n 7r2 TT 

r I- Si +S2:7r 

/ : (Ti X ■ ■ ■ X cr„ ^ (To G r 
AT h si : TTi A (Ti — ^ (Ti tti 
A ■■■ 

AT h s„ : 7r„ A o-„ ^ (7„ 7r„ 
r h /(si,...,s„):c7o ^ ao 



[cong.2] 



Fig. 17. Refinement of tlie typing rules for implicit restriction 



Implicit restriction made explicit Let us first consider one form of implicit re- 
striction where we update all typing rules which have to do with potentially many- 
sorted contexts. Basically, we want to state that the type of a compound strategy 
si; S2 or si + S2 is dictated by a many-sorted argument (if any). As for congru- 
ences, we want to state that generic strategies can be used as argument strategies. 
Finally, we also need to relax strategy application so that we can apply a generic 
strategy without further precautions to any term. This approach to implicit restric- 
tion is formalised in Figure 17. The updated rule [apply] for well-typedness of strat- 
egy applications states that a strategy s of type tt can be applied to a term t of type 
r, if the domain of tt covers r. As an aside, note that the definition is sufficiently 
general to cope with type-changing strategies. As for •; •, we relax the definition 
of composable types to cover composition of a many-sorted type and the generic 
type TP in both possible orders (cf. [comp.3] and [comp.4]). As for • + •, we do not 
insist on equal argument types anymore, but we employ an auxiliary judgement 
r h TTi n 71-2 TT for the greatest lower bound w.r.t. (cf. [choice]). Finally, we 
relax the argument types for congruences via the relation. 



Unicity of typing vs. principal types The value of the refinement in Figure 17 is 
that we are very precise about where restriction might be needed. Moreover, we can 
maintain UOT for this system. A problem with the above approach is that several 
typing rules need to be refined to become aware of ^p. There is a simpler approach 
to implicit restriction. We can include a typing rule which models that a generic 
strategy can also be regarded as a many-sorted strategy. The rule is shown in Fig- 
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Well-typedness of strategies 



r h s : TT A tt' 71" 
r h s : tt' 



r l-s:7r 



implicit! 



Fig. 18. Implicit restriction relying on principal types 



ure 18. This new approach implies that UOT does not hold anymore for strategies. 

However, one can easily see that the multiple types arising from implicit restric- 
tion are closed under r^r- Thus, one can safely replace UOT by the existence of a 
principal type. We simply regard the most generic type of a strategy as its principal 
type. Note that UOT still holds for strategy application. 



4.4 Strategies of type T U ( • ) 



Combinators In Figure 19, the reduction semantics of the combinators for type- 
unifying traversal is defined. Thereby, we complete the combinator suite of S'^. For 
brevity, we omit the typing context which might be needed for the type-dependent 
reduction of ■ < -. The combinator O (") is defined in [red+]. Every child U is pro- 
cessed, and pairwise composition is used to compute a final term t2n-i from all the 
intermediate results. Note that pairwise composition is performed from left to right. 
This is a kind of arbitrary choice at this point, and we will come back to this issue 
in Section 5.5. Note also that the reduction semantics for O ( ) does not specify a 
total temporal order on how pairwise composition is intertwined with processing 
the children. There are at least two sensible operational readings of [red+]. Either we 
first process all children, and then we perform pairwise composition, or we immedi- 
ately perform pairwise composition whenever a new child has been processed. The 
negative rules for Q (") similar to those of □(•) and <>{■). A constant cannot 
be reduced as in the case of O(-) (cf. [red- .i]). Reduction fails if any of the children 
cannot be processed as in the case of □(■) (cf. [red-. 2]). There is also the possibility 
that pairwise composition fails (cf. [red-. 3] and [red-. 4]). 

Selection of a child is more easily explained. The overall scheme regarding both the 
positive rule and the two negative rules for [!(■) is very similar to the combinator 
O(-). The combinator tl(-) differs from <>{■) only in that the shape of the input term 
is not preserved. Recall that in the reduct of an application of O(-), the outermost 
function symbol and all non-processed children carry over from the input term. 
Instead, selection simply yields the processed child. As in the case of O(-), we 
cannot process constants ([sei-.i]), and we also need to fail if none of the children 
admits selection (cf. [sei-.2]). 

Let us finally consider the auxiliary combinators A and si || S2. The combinator A. 
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Syntax 



s ::- 



I o'{s) I m I 



± 



s W s 



Reduction of strategy applications 
Positive rules 

s@h ^ t[ 

A ... 

A S @ ^ in 

A So @ (4+1, t^)-^ 4+2 

A ■■■ 

0'°{s)@fiti,t2,...,tn)^t'^n-l 

3i e {l,...,n}. 



[red+] 

[sel+] 
[void+] 



Negative rules 
0^°(s)@c^ t 

0^°(5)@/(ti,...,U-^T 



Ispawn^ 



[red-.l] 



red-. 2 



S@tl^ t[ 



A 



A s @ i„ 4 

A So@(tl,t2)'-^T 



o'°(s)@/(ti,t2,...,tn)-^r 

3iG {3,...,n}. ( 

S@tl^ t[ 

A ■■■ 

A s @ t„ ^ 4 

A So@(tl,t2)-^4+l 

A • • • 

A So@(4+»-2.0-"T) 

0'°(s)@/(ti,t2,...,U-^T 



[red -.3] 



tJ(s)@c^ t 



[red -.4] 



[se|-.l] 



A 



A S @ t„ ^ t 



t|(s)@/(tl,...,tn)'-T 
Si II S2 @i T 



[se|-.2] 



[spawn 



Fig. 19. Type-unifying combinators 
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Syntax 



TU(r) 



Well-formedness 
of strategy types 

r hr 

r hTU(T) 

Genericity relation 

r I- T A r h r' 

r' ^ r TU(r) 
Composable types 



r hTT 



pi.3 



[less.2] 



r h TTl ; 7r2 ^ TT 



r h T A r h r' 



r h TU(r);T ^r' TU(r') 



[comp.5] 



Well-typedness 
of strategies 

r h So : (r, t) ^ T 
A r h s:TU(r) 
r hO'°(s):TU(r) 

r hs:TU(T) 
r htt(s):TU(T) 



r h. 



^TU(()) 



r hsi:TU(Ti) 
A r hs2:TU(r2) 
r hsi II S2:TU((ri,r2)) 



r hs:7r 



red 



[sel] 



void 



IspawnJ 



Fig. 20. TU(-) — The type of generic type-unifying strategies 



simply accepts any term, and reduction yields the empty tuple (). The combinator 
is in a sense similar to e as it succeeds for every term. However, the term reduct 
is of a trivial type, namely () regardless of the type of the input term. The strategy 
si II S2 applies both strategies to the input term, and the intermediate results are 
paired (cf. [spawn+]). If either of the strategy applications fails, si \\ S2 fails, too (cf. 
[spawn ]). Note that one could attempt to describe the behaviour underlying A. and 
• II ■ by the following strategies that employ rewrite rules: 



Void = X ^ {) 

Spawn (z^i, 1/2) =X ^ {Yi, Y2) where Yi = z^i @ X where ¥2 = iy2@X 

However, the above rewrite rules and the pattern variables would have to be gener- 
ically typed. This is in conflict with the design decisions that were postulated by 
us for Si,. The types of rewrite rules in 5"' are required to be many-sorted. All 
genericity should arise from distinguished primitive combinators. Recall that these 
requirements are meant to support a clean separation of genericity and specificity, 
a simple formalisation of S' , and a simple implementation of the calculus. 
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The generic type TU (•) The fomialisation of the generic type (constructor) TU(-) 
is presented in Figure 20. We basically have to perform the same steps as we dis- 
cussed for TP. Firstly, well-formedness of TU(-) is defined (cf. [pi.s]). Secondly, the 
type scheme underlying TU(t) is defined (cf. [iess.2]). Thirdly, the auxiliary judge- 
ment for sequential composition is updated (cf. [comp.5]) to describe how TU(-) is 
promoted. Consider a sequential composition Si;s2 where si is of type TU(r), 
and S2 is of type r t' . The result is of type TU(r'). Note that a many-sorted 
strategy followed by a type-unifying strategy or the sequential composition of two 
type-unifying strategies do not amount to a generic strategy. Still we could include 
these constellations in order to facilitate implicit restriction. The typing rules for 
the type-unifying strategy combinators are easily explained. Reduction of all chil- 
dren to a type r via 0*° (■^) requires So to be able to map a pair of type (r, r) to a 
value of type r in the sense of pairwise composition, and the strategy s for process- 
ing the children has to be type-unifying w.r.t. the same r (cf. [red]). The typing rule 
for the combinator ji( ) directly states that the combinator is a transformer on type- 
unifying strategies (cf. [sei]). The typing rule for A. states that every type is mapped 
to the most trivial type (cf. [void]). Finally, ■ || ■ takes two type-unifying strategies, 
and produces another type-unifying strategy. If TU(ri) and TU(r2) are the types 
of the argument strategies in si || S2, then TU((ti, T2)) is the type of the resulting 
strategy (cf. [spawn]). 



Assembly of S'^ Let us compose the ultimate calculus S'^. It accomplishes both 
type-preserving and type-changing strategies. Furthermore, tuples are supported. 
Ultimately, the generic types TP and TU(-) are enabled. We favour implicit restric- 
tion for S'^. For convenience, we summarise all ingredients for S'^: 

• The basic calculus 5*0 (cf. Figure 8) 

• Many-sorted type-preserving strategies (cf. Figure 10) 

• Many-sorted type-changing strategies (cf. Figure 11) 

• Polyadic strategies (cf. Figure 12) 

• The combinators □(•) and O(-) (cf. Figure 13) 

• The generic type TP (cf. Figure 14) 

• The combinators Q (■)' tl(')' — ' ^^'^ ' W ' (^f- Figure 19) 

• The generic type TU(-) (cf. Figure 20) 

• Strategy extension (cf. Figure 15) 

• Implicit restriction (cf. Figure 17) 

Theorem 4 The calculus S'^ obeys the following properties: 

(1) Strategies satisfy UOT, i.e., ... (cf. Theorem 3). 

(2) Strategy applications satisfy UOT i-c., ... (cf. Theorem 1). 

(3) Reduction of strategy applications satisfies subject reduction, 

i.e., for all well-formed contexts T, strategies s, terms t, t', term types t, t', 
and strategy types tt: 
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r \- s-.TT A r \-t:T A r^r'^rTT A F \- s^t-^t' implies F \- t' : t'. 

We omit the proof because it is a simple combination of the ideas from Proof 2 
and Proof 3. In the former proof, we generaUsed the scheme for many-sorted type- 
preserving strategies from Proof 1 to cope with type-changing strategies as type- 
unifying strategies are, too. In the latter, we generalised Proof 1 in a different di- 
mension, namely to cope with generic strategies as type-unifying strategies are, 
too. It is easy to cope with implicit restriction instead of explicit restriction in S'jp, 
neither does the introduction of tuples pose any challenge. 



5 Sophistication 

In the previous two sections we studied the reduction semantics and the type sys- 
tem for all the S'^ primitives. In this section, we want to complement this devel- 
opment with a few supplementary concepts. Firstly, we will consider a straight- 
forward abstraction mechanism for strategy combinators, that is, strategy defini- 
tions. Secondly, we will refine the model underlying the formalisation of S'^ to 
obtain a reduction semantics which does not employ typing judgements in the re- 
duction semantics anymore. Thirdly, we describe a form of overloaded strategies, 
that is, strategies which are applicable to terms of several types. Fourthly, we in- 
troduce some syntactic sugar to complement strategy extension by a sometimes 
more convenient approach to the inhabitation of generic types, namely asymmetric 
type-dependent choice. Finally, we will discuss the potential for more general or 
additional traversal combinators. 



5.1 Strategic programs 

The syntax and semantics of strategic programs is shown in Figure 21. A strate- 
gic program is of the form F A s. Here F corresponds to type declarations for the 
program, A is a list of strategy definitions, and s is the main expression of the 
program. A strategy definition is of the form ip{ui, . . . jUn) — s where ui, Un 
are the formal parameters. The parentheses are omitted if cp has no parameters. We 
assume that the RHS s does not contain other strategy variables than vi, ly^- 
Furthermore, we assume a-conversion for the substitution of strategy variables. In 
the judgement for the reduction of strategy applications, we propagate the strat- 
egy definitions as context parameter A (cf. [prog+/-]) so that occurrences of strategy 
combinators can be expanded accordingly (cf. [comb+/-]). Note that the reduction 
judgement for strategy applications carries F in the context in order to enable strat- 
egy extension. 

To consider well-formedness and well-typedness of strategic programs we need to 
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Syntax 



p ::= r A s (Programs) 
u (Strategy variables) 

r ::= ••• \ ip: ttx-'-xtt^ttIv: TT (Contexts) 
A ::= I A, A I ip{ij, ■■■ ^u) = s (Definitions) 
s ::=■■■ \ u \ (p{s, ... ,s) (Strategies) 



Reduction 
of programs 

r, A \- s@t^r 
r As@t-^r 



p@t-^r 



Iprog 



+/- 



Reduction 

of strategy applications 



r, A h s@t^r 



A s' = Si, . . . , l/„ H^- Sn} 

A r,A h s'@t--^r 
r,A h(^(si,...,s„)@Wr 



[comb+/ 



Fig. 21. Strategic programs: syntax and reduction semantics 



extend the grammar for contexts T as it was already indicated in Figure 21. Contexts 
may contain type declarations for strategy combinators and types of strategy vari- 
ables. A strategic program is well-formed if the strategy definitions and the main 
expression of a program are well-typed (cf. [prog]). A strategy definition is well- 
typed if the body can be shown to have the declared result type of the combinator 
while assuming the appropriate types of the formal parameters in the context (cf. 
[def.s]). When a strategy variable is encountered by the well-typedness judgement, 
its type is determined via the context (cf. [arg]). An application of a combinator is 
well-typed if the types of the actual parameters are equal to the types of the formal 
parameters (cf. [comb]). We could also elaborate the latter typing rule to facilitate 
implicit restriction. This would allow us to place generic strategies as actual pa- 
rameters on many-sorted parameter positions of strategy combinators. 



Type-parameterised strategy definitions Let us also enable type-parameterised 
strategy definitions. In Figure 23, we give typing rules to cope with type parame- 
ters in strategy definitions and combinator applications. The formalisation is pretty 
standard. We assume a-conversion for the substitution of type variables. Term- 
type variables are regarded as another form of a term type. The extension of the 
grammar rule for T details that types of strategy combinators might contain type 
variables that are quantified at the top level. Type variables are scoped by the cor- 
responding strategy definition (cf. [def.4]). If the well-formedness judgements for 
types encounter a term type variable, it has to be in the context (cf. [tau.4]). The 
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Well-typedness 
of programs 

rhAAri-s:7r 
h r A s:7r 

Well-typedness 

of strategy definitions 

r h0 

r h Ai A r h A2 
r h Ai,A2 



r l-p:7r 



prog 



r hA 



[def.l] 



def.2 



Well-typedness 
of strategies 



r l-s:7r 



1/ : TT G r 
r h i/:7r 

(/9 : TTi X • • • X 7r„ — >■ TTo G r 
AT h si : TTi 
A ... 

AT h s„ : 7r„ 

r l-(^(si,...,Sn):7ro 



arg 



comb 



: TTi X ■ ■ ■ X 7r„ — > TTo G r 
A r, Z/i : TTl, i/„ : TTn I- s : TTo 
r I- ip{ui, ...,Un) = S 



def.3 



Fig. 22. Well-typedness of strategic programs 



application of a combinator (p involves type application, namely substitution of the 
type variables by the actual types (cf. [comb-foraii]). For brevity, we do not refine the 
reduction semantics from Figure 21. 



5.2 F-free strategy extension 



When we introduced strategy extension, we encountered a complication regarding 
the reduction semantics. In order to define the type- safe application of a many- 
sorted strategy s in a generic context, we have to perform a run-time comparison of 
the type of the given term and the type of s. To this end, we added the typing context 
r to the judgement for the reduction of strategy applications, and typing judgements 
were placed as premises in the rule for • < • (cf. Figure 15). We would like to obtain 
a form of semantics where typing and reduction judgements are strictly separated. 
We will employ an intermediary static elaboration judgement to annotate strategies 
accordingly. Furthermore, we assume that terms are tagged by their types. The 
resulting reduction semantics is better geared towards implementation. 
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Syntax 



a 

T 

r 

A 

s 



a 



: Va, . . . , a. TT X ■ ■ ■ X TT 

ip[a,...,a]{i',...,v) = s 

ip[T,...,T]{s,...,s) 



(Term-type variables) 
(Term types) 
TT (Contexts) 
(Definitions) 
(Strategies) 



Well-formedness of term types 



V hr 



a G r 
r ha 



tau.4 



Well-typedness of strategy definitions 

(f : Vai, . . . , am- tti x ■ ■ ■ x 7r„ ^ ttq G T 
A T,ui : TTi, . . . , i/n : 7r„, ai, . . . , h s : ttq 

r \- ip[ai,...,am\il^l,---,l^n) = s 

Well-typedness of strategies 

(fi : Vai, . . . , am- tti x • • • x 7r„ ^ ttq G T 
Ari-riA...Ari-r,„ 
AT \- si:Tri{ai^Ti,...,am'-^Tm} 
A • • • 

AT \- Sn-.TTniait^Ti, . . . ,am^Tm} 
r h (y9[ri, ...,Tm\{si,---,Sn): 7To{ai ^Ti,...,am^ Tm} 

Fig. 23. Type-parametrised strategy definitions 



r hA 



[def.4] 



r hsiTT 



[comb— forall] 



Static elaboration So far, we only considered well-typedness and reduction judge- 
ments. We want to refine the model for the formalisation of S'^ to include a static 
elaboration judgement of the following form: 



r \- s' 
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Static elaboration of strategies 



r h s s' 



r h ^ tr ^ ti ^ t.f 



r h e e 



[rule"^] r h Si s'l 

AT \- s'2 
^ r h Si + S2 --^ s{ + S'r, 

[f^'i'"] r h C C 



choice"^ 



[cong'^.l] 



r h S-^S' 

r I — ^ s -1 s' 

r h si s'^ 
AT h S2 S2 
r I- si; S2 s'l; S2 



neg 



seq 



r h Si s'l 



A 



AT h s„ s^ 



r h /(Si, . . . ,Sn) /(s'l, . . . 



1 *n) 



[cong'".2] 



Fig. 24. General scheme of static elaboration 



The general idea of static elaboration is that the input strategy s can be transformed 
in a semantics-preserving manner. There are several potential applications of static 
elaboration. We will emphasise its application to the problem of eliminating typing 
judgements in the reduction semantics of ■ < ■. In addition, one could employ static 
elaboration for the definition of syntactic sugar or for program optimisation QJ VU1| ]. 
The semantic model for typeful strategies needs to be updated to consist of three 
phases: 
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Syntax 



s ■.:= ■■ ■ \ s-.TT (Strategies) 
t ::= ■ ■ ■ \t:T (Terms) 



Static elaboration 
of strategies 

r hs-.ir' 

A r h s s' 

r l-s<7r^s':7r'<7r 



r \- s' 



extend"" 



Reduction 

of strategy applications 

Positive rule 

s:t ^ t' < @t -.T-^t' 

Negative rules 

s@t : r t 

„ i. ^11 

T T 

s:t ^ t' <T@t : t" ^ 
Fig. 25. Strategy extension relying on type tags 



s@t^r 



extend 



'+ 



[extend' .l] 



[extend' .2] 



(1) The given strategy s is checked to be well-typed. 

(2) s is elaborated resulting in a strategy s'. 

(3) Given a suitable term t, the strategy s' is applied to t to derive a reduct. 

These phases obviously map nicely to an implementational model where type check- 
ing and elaboration is done once and for all statically, that is, without insisting on 
an input term. In general, static elaboration might be type-dependent, that is, the 
typing context F is part of the elaboration judgement as in the case of the well- 
formedness and well-typedness judgements. In Figure 24, we initiate the general 
scheme of static elaboration. We give trivial rules for all combinators of the basic 
calculus S'q such that we descend into compound strategy expressions. So far, the 
judgement encodes the identity function on strategy expressions. Below, we will 
provide a special rule for the elaboration of applications of • < •. 



Type tags In order to eliminate the typing premise for the extended strategy in 
the reduction semantics of • <l • we replace strategy expressions of the form s <| tt 

by s -.n' <\7r where tt' denotes the actual type of s. Here, we reanimate the nota- 
tion of type- annotated strategies that was already proposed earlier. Since the type 
is captured in the elaborated strategy expression, the type of s does not need to 
be determined during reduction anymore. Furthermore, we assume that terms are 
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Reduction of strategy applications 



s@t^ r 



[cong+.l] 



A ... 



f{si, . . . ,Sn)@ f{tl, . . . ,tn) -.T ^ fit[, . . . X) -r 



□ (s) @c:t^c:t 



[cong+.2] 
[all+.l] 



A ... 



ais)@f{h,...,tn):r^f{t[,...,t'J:T 



[all+.2] 



Fig. 26. Refined reduction semantics to cope with tagged terms 



tagged by their sorts. Obviously, this assumption is useful to also get rid of the 
type judgement for the term t in the reduction semantics for • • • <n@t. Thus, the 
original type dependency reduces to a simple comparison of type tags of the ex- 
tended strategy and the term at hand. The rules for static elaboration and the new 
reduction semantics of strategy extension is shown in Figure 25. The elaboration 
rule [extend^] deviates from the trivial default scheme of static elaboration by actu- 
ally adding the inferred type as a tag. The deduction rule [extend'+] defines the new 
reduction semantics of strategy extension. 



Tagged terms The assumption that terms are tagged by a type has actually two 
implications which need to be treated carefully. Firstly, we should better assume 
that terms are consistently tagged at all levels. This means that the terms consti- 
tuting a rewrite rule have to be tagged, too. Secondly, we need to make sure that 
all reduction rules appropriately deal with tagged terms. In fact, we need to update 
the reduction semantics of congruences and generic traversal because they are not 
prepared to deal with tags. In Figure 26, we illustrate the new style of traversal. For 
brevity, we only show the positive rules for congruences and for the combinator 
□(•). 



59 



5.3 Overloaded strategies 



We want to consider an intermediate form of genericity, namely overloaded strate- 
gies. Overloading means that we can cope with strategies which are applicable to 
terms of a number of sorts. We introduce a designated combinator ■ & ■ to gather 
strategies of different types in an overloaded strategy. The combinator ■ & ■ is type- 
dependent in the same way as strategy extension via ■ < ■. In fact, we say that ■ & ■ 
performs symmetric type-dependent choice. The type of the ultimate term decides 
which side of the choice is attempted. Hence, this choice is not left- or right-biased, 
nor is it controlled by success and failure. We use the notation ■ & ■ for the construc- 
tion of both overloaded strategies and the corresponding strategy types. 

Example 17 Consider the following constructors for naturals and integers: 



one : NatOne 
succ : NatOne - 
zero : NatZero 
notzero : NatOne - 
positive : NatZero 
negative : NatOne - 



NatOne 

NatZero 
> Int 
Int 



NatZero includes 0, whereas NatOne starts with 1. Integers are constructed via two 

branches, one for positive integers including zero, and another for negative inte- 
gers. We use NO as stem of variables of sort NatOne. Let us define two overloaded 
strategies iNC and Dec which are capable of incrementing and decrementing terms 
of the three above sorts: 



iNC : NatOne ^NatOnekNatZero^ NatZero k Int 

iNC ^ NO^ succ{NO) 

& zero — > notzero{one) -\- notzero{lNC) 

& positive(lNC) -I- negative(DEc) -\- negative{one) 

Dec : NatOne NatOne & NatZero NatZero & Int 

Dec = succ{NO) NO 

& notzero(one) zero + nofzero(DEC) 

& positive(DEC) -I- negative{lNC) -\- positive{zero) 



Int 



positive{zero) 
Int 



negative{one) 



The strategies are defined via symmetric type-dependent choice with three cases, 

one for each sort. Otherwise, the functionality to increment and decrement is de- 
fined by rewrite rules or in terms of congruences on the appropriate constructors. 
As an aside, it is necessary to assume implicit restriction for overloaded strategies 
in order to claim well-typedness for the above definitions. This is because the using 
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Syntax 



TT = • 
S = ■ 



■ ■ I TT & TT 
• • \ S&LS 



Well-formedness 
of strategy types 



r Htt 



r h TTi A D0M(7ri) ^ TSi 
AT h 7r2 A DOM(7r2) rs2 
A TSi n rs2 = 



r h TTi &: 7r2 



[pi.4] 



Domains 
of strategies 



DOM(7r) ^ 7S 



Dom(t -> r') ^ {t} 

DOM(7ri) ^ TSi 
A DOM(7r2) ^ TS2 
DOM(7ri & 7r2) 7^1 U W2 



dom.l 



dom.2 



Genericity relation 

r h TT A r h tt' 

TT -<r tt' 
TTi TT A 7r2 ti" 

TTl & 7r2 TT 



TT TT 



[less.S] 



[less.4] 



Composable types 



tt; tt' tt" 



7ri^7rl&7r'/ 

A 7r2 = TT^ & TT^' 

A r h 7r'i;7r^ vr^ 
AT h <;7r^^ ^ ^ 
r h TTl ; 7r2 &; 

of strategies 

r h si : TTl 

AT h S2 : 7r2 
AT h TTl &: 7r2 
r h si & S2 : TTl & 7r2 

Reduction 

of strategy applications 

3zG{l,2}. ( 

r ht:r 
AT h s : TTj 
A D0M(7ri) TBj 

A r G TSi 
AT h @ t r) 
r l-si&S2@t-^r 



|comp.6| 



r h s : TT 



amp 



r \- sm^r 



lamp 



+/- 



Fig. 27. Overloaded strategies 



occurrences of iNC awJ DEC are used for specific sorts covered by the overloaded 
types of iNC and DEC. 
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Typing rules In Figure 27, the reduction semantics for overloaded strategies and 
the corresponding typing rules are defined. The type of an overloaded strategy is of 
the form ri ^ t{ & ■ ■ • & ^ r^. The type models strategies which are applica- 
ble to terms of types ri, . . . , t„. If such a strategy is actually applied to a term of 
type Ti, the result will be of type r/. We use an auxiliary judgement DOM(7r) ^ ts 
to obtain the finite set ts of term types admitted as domains by a strategy type tt. We 
do not attempt to cover generic types in this judgement because symmetric type- 
dependent choice cannot involve a generic strategy. This is because if one branch 
would be generic, there are no sorts left to be covered by the other branch. Indeed, 
we require that the domains of the types composed by • & • must be disjoint (cf. 
[pi.4]). This requirement enforces immediately UOT of strategy applications. Fur- 
thermore, the requirement also ensures that type-dependent choice is deterministic, 
and hence does not overlap with • + •, i.e., choice controlled by success and failure. 
In [iess.3]-[iess.4], wc Update the relation on strategy types. To this end, we em- 
ploy an equivalence = on strategy types modulo associativity and commutativity of 
• & •. Rule [iess.3] models that tt is less generic than any type tt' which is equivalent 
to TT & tt". Clearly, this rule is needed to relate simple many-sorted and overloaded 
strategy types to each other. The rule also relates overloaded strategy types among 
each other. Rule [iess.4] models that the type of an overloaded strategy is less generic 
than another type tt, if both components tti and ^2 of the overloaded type are also 
less generic than tt. This rule relates overloaded strategy types and generic types to 
each other. In this elaboration of ^r, the simple many-sorted strategies are the least 
elements, and the generic types are the greatest elements. 



Reduction semantics An overloaded strategy is constructed by symmetric type- 
dependent choice si & S2 where the types of the arguments si and S2 have to admit 
the construction of an overloaded strategy type (cf. [amp]). As for the reduction 
semantics of si & S2, the appropriate s , is chosen depending on the type of the input 
term (cf. [amp+]). The kind of typing premises in the reduction semantics are similar 
to the original definition of strategy extension, and static elaboration could be used 
again to eliminate them. We should note that the refined reduction semantics from 
Section 5.2 is not prepared to cope with overloaded strategies. A corresponding 
generalisation does not pose any challenge. 



Expressiveness Although overloading is convenient in strategic programming, it 
can usually be circumvented with some additional coding effort. To reconstruct Ex- 
ample 17 without overloading, we had to define separate strategies for the different 
sorts NatZero, NatOne, and Int. Overloading is convenient to describe many-sorted 
ingredients of a traversal in the case that the traversal deals with several term types 
Ti, . . . , r„ in a specific manner. If we use overloading we can compose the many- 
sorted ingredients for ri, . . . , r„ in one overloaded strategy. It is then still possible 
to extend the overloaded strategy in different ways before we pass it to the ultimate 
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traversal scheme. Without overloading, we need to immediately represent the sev- 
eral many-sorted ingredients as a generic strategy by iterating strategy extension 
for each Tj. Also, while the type system enforces that the ri, . . . , r„ are distinct 
in the case of overloading, there is no such guarantee without overloading. In ad- 
dition to the convenience added by overloading, it is also worth mentioning that 
overloading can be used to reconstruct generic strategies in some restricted man- 
ner. If we consider a fixed signature, then we can represent the signature-specific 
instantiations of generic strategy types as overloaded strategy types. Consider, for 
example, the type TP. We can reconstruct TP by overloading all r ^ r for all 
well-formed r according the given signature. Note that this construction becomes 
infinite if we enable tuple types, but it is finite if we restrict ourselves to traversal 
of many-sorted terms. Based on these signature-exhausting overloaded types, we 
could represent the generic traversal combinators as signature-specific overloaded 
combinators defined in terms of the many- sorted congruences for all the available 
function symbols. 



Bibliographical notes When we compare symmetric type-dependent choice to 
other notions of overloading or ad-hoc polymorphism QCW85I , |WB89| , [fon950 , we 
should note that these other notions are usually based on a form of declaration 
as opposed to a combinator. Also, other models of overloading usually perform 
overloading resolution at compile time whereas the dispatch for overloaded strate- 
gies happens at run-time. In [ |CGL95| ], an extended A-calculus A& is defined that 
employs type-dependent reduction in a way very similar to our approach. Type- 
dependent reduction is used to model late binding in the object-oriented sense. 
More precisely, type-dependent reduction is used in A& to resort to the most ap- 
propriate "branch" of a function based on the run-time type of the argument. This 



work also discusses the relation of overloading and intersection types QCDCVSl 



BDCd95| ] . This is interesting because, at a first glance, one could envision that in- 
tersection types might be useful in modelling overloading. For short, intersection 
types are not appropriate to model overloading if type-dependent reduction is in- 
volved. Using intersection types, we say that a function / is of type a fl 6 if / can 
play the role of both an element of type a and of type b. Overloading in the sense of 
Si^ and A& relies on type-dependent reduction, and thereby the selection of the role 
is crucial for the computation. This facet goes beyond the common interpretation 
of intersection types. 



5.4 Asymmetric type-dependent choice 



So far, the only way to turn a many-sorted strategy s into a generic one is based 
on the form s <\tt. This kind of casting implies that the lifted strategy will fail at 
least for all term types different from the domain of s. This is often not desirable, 
and hence, an extension usually entails a complementary choice. In the present 
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section, we want to argue that the separation of lifting (by ■ < •) and completion 
by ■ + ■ and friends is problematic. It is however possible to support a different 
style of inhabitation of generic types. We will define a corresponding combinator 
for asymmetric type-dependent choice. While the combinator • & • for symmetric 
type-dependent choice from Section 5.3 was linked to the notion of overloading, the 
upcoming asymmetric form does not rely on overloading. In fact, the corresponding 
left-biased and right-biased forms ■ ■ and ■ -<fe^ ■ can be regarded as syntactic 
sugar defined in terms of strategy extension. Asymmetric type-dependent choice 
means to apply the less generic strategy if this is type-safe, and to resort to a more 
generic strategy otherwise. If we do not consider overloading, then this form of 
choice favours the many-sorted operand if this is type-safe, and it resorts to the 
generic default otherwise. 

Example 18 To motivate the idea of asymmetric type-dependent choice, let us re- 
consider the traversal scheme StopTD that was defined earlier. We repeat its def- 
inition for convenience: 

StopTD : TP ^ TP 
StopTD (i/) = □(StopTD (i/)) 

Left-biased choice controlled by success and failure is used here to first try the 
generic argument s o/StopTD(s) but to descend into the children if s fails. Let 
us assume that s was obtained from a many-sorted strategy s' by strategy extension 
as in s' < TP. It is important to note that s could fail for two reasons. Firstly, s is 
faced with a term of a sort different from the domain of s'. Secondly, s' is applicable 
as for the typing, but s' is defined in a way to refuse the given term, e.g., because of 
unsatisfied preconditions. These two sources of failure are not separated in the def- 
inition of StopTD. In the present formulation, StopTD will always recover from 
failure of s and descend into the children. In fact, StopTD will always succeed 
because □(•) at least succeeds for leafs. 



Syntactic sugar We conclude from the above example that type-mismatch and 
other sources of failure are hard to separate in a programming style based on • < •. 
We improve the situation as follows. We introduce asymmetric type-dependent 
choice. In the left-biased notation si <4£- S2, the left operand si is regarded as 
an update for the default S2. Hence, we call this form left-biased type-dependent 
choice. The many-sorted strategy si should be applied if the type of the term at 
hand fits, and we resort to the generic default S2 otherwise. For brevity, we do not 
take overloaded strategies into account. One essential ingredient of the definition of 
asymmetric type-dependent choice is a type guard, that is, a generic strategy which 
is supposed to accept terms of a certain sort and to refuse all other terms. A type 
guard is constructed from a many-sorted restriction of e which is then lifted to the 
generic type of choice. Here is the syntactic sugar for type guards and asymmetric 
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type-dependent choice: 

T<l7=(e>r— >t)<17 
Si <-<fe- S2 = Si<7r + {-'{T< TP); S2) where Si : r — > r', S2 : tt 
Si S2 = ^2 -^-fe- Si 

A fully formal definition of this syntactic sugar could be given via the elaboration 
judgement discussed earlier but we omit this definition for brevity. The definition 
of si S2 employs a negated type guard -1 (r < TP) to block the application of 
the generic default S2 in case si is applicable as for typing. 

Example 19 Let us define a variant of StopTD which interprets failure of the 
argument strategy as global failure. This can be used for some form of "design by 
contract". If the argument strategy ever detects that some precondition is not met, 
the corresponding failure will be properly propagated as opposed to accidental 
descent. 

StopTD' : Ma. {a^a)^ TP 
STOPTD'[a](i/) = □(STOPTD'[a](i/)) 

StopTD' is different from StopTD in that the argument of StopTD is a generic 
strategy whereas it is many-sorted in the case o/StopTD'. To this end, the type of 
StopTD' involves a type parameter for the sort of the argument. The asymmetric 
type-dependent choice to derive a generic strategy from the argument is part of the 
definition o/StopTD'. 

Example 20 We should mention that type guards are useful on their own. Recall 
the illustrative traversal problem (IV) to collect all natural numbers in a tree. The 

encoding from Example 14 relies on a user-defined strategy NAT to test for naturals 
based on the congruences for the constructors of sort Nat. The syntactic sugar for 
type guards allows us to test for arbitrary sorts without the cumbersome style of 
enumerating all constructors. This is illustrated in the following definition of (IV) 
where we use the notation for a type guard for naturals instead of relying on the 
user-defined strategy NAT.- 

(IV) = STOPCRUSH[JVatList](JVat<]TU(JVat); Singleton, Nil, Append) 



Complementary forms of choice It is instructive to compare the different forms 
of asymmetric choice encountered in the present paper. In the case of si ^ S2, the 
success of si rules out the application of S2. In the case of si <-&ir- S2, the mere type 
of si decides if the application of S2 will be ever considered. To understand this 
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twist, consider the following strategy approximating si <-<fe- S2: 
Si < 7r2 S2 where S2 is of type 7r2 

This formulation attempts to compensate for the type guard in the definition of 
asymmetric type-dependent choice by resorting to left-biased choice controlled 
by success and failure. That is, we attempt to simulate left-biased type-dependent 
choice by left-biased choice controlled by success and failure. This attempt is not 
faithful since S2 might be applied to a term t even if the types of Si and t fit, namely 
if Si fails on t. 

To summarise, choice between strategies of the same type is solely modelled by 
the combinators ■ + ■ and friends that are controlled by success and failure. Non- 
deterministic and asymmetric choice differ in the sense if there is a preferred order 
on the arguments of the choice. For convenience, we might accept different types 
for the argument strategies of • -I- • and friends. But then we restrict the type of the 
choice to the greatest lower bound of the types of the arguments. By contrast, type- 
dependent choice composes strategies of different types, and the type of the choice 
extends to the least upper bound of the types of the arguments. The corresponding 
combinators are not at all controlled by success and failure. Instead, the type of the 
term at hand determines the branch to be taken. The arguments in an asymmetric 
type-dependent choice are related via ^r> whereas the domains of the arguments 
in a symmetric type-dependent choice are required to be disjoint. In conclusion, 
choice by success and failure and type-dependent choice complement each other. 
The division of labour between the two kinds of choice was also nicely illustrated 
in Example 17. 

5.5 Variations on traversal 

The selection of the traversal primitives of S'^ has been driven by the requirement 
not to employ any universal representation type. For that reason the children are 
never directly exposed to the strategic program. Instead, one has to select the ap- 
propriate combinator to process the children. We want to indicate briefly that there 
is a potential for generalised or additional traversal primitives while keeping in 
mind the aforementioned requirement. 

Order of processing children The reduction semantics of the traversal primitives 
left the order of processing children largely unspecified. As for □(•), the order does 

not seem to be an issue since all the children are processed anyway and indepen- 
dently of each other. Note however that the order becomes an issue if we anticipate 
the possibility that processing fails for one child or several children. Then, different 
orders will not just lead to different execution times, but even program termination 
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might depend on the order. As for O (■), a flexible order is desirable for yet another 
reason. That is, one might favour the left-most vs. the right-most child that can be 
processed. The actual choice might be a correctness issue as opposed to a mere 
efficiency issue. To cope with such variations, one can consider refined traversal 
combinators such as Oo{s) where we assume that the order of processing children 
is constrained by o. There are the following options for such an order constraint o: 

• "— >" — processing from left to right 

• " — processing from right to left 

• unspecified 

As for the type-unifying traversal combinators, order constraints make sense as 
well. In Oo° ("S)' the constraint o could be used to control how the pairwise compo- 
sition So is applied to the processed children. A simple investigation of the original 
formalisation of 0^° (s) in Figure 19 makes clear that a left-to-right reduction was 
specified (although it was not constrained if pairwise composition is intertwined 
with processing the children). A certain order o for reduction might be relevant to 
cope with combinators So which do not admit associativity and/or commutativity. 
As for selection via J}o(s), basically the same arguments apply as to Oo(s). 

Pairwise composition vs. folding It turns out that reduction as modelled by the 
combinator O ( ) can be generalised. Instead of separating the aspects of process- 
ing the children and composing intermediate results, we can also define reduction 
so that the way how a child is processed depends on previously processed children. 
In fact, one can define a combinator (|-, ■[) which folds directly over the children of 
a term very much in the sense of the folklore pattern for folding a list. Note how- 
ever that we have to cope with an intentionally heterogeneous list corresponding 
to the children of a given term. That is, in folding over the children of a term, we 
need a generic ingredient to operate on a given child and the intermediate result ob- 
tained from previous folding steps. The reduction semantics of the strategy (\sq, sd) 
is defined in Figure 28. The first argument Sq encodes the initial value for folding. 
In the case of a constant symbol, sq defines the result of folding (cf. [foid+.i]). For 
nontrivial terms, we fold over their children by repeated application of the second 
argument Sc (cf . [foid+ .2] ). Without loss of generality, (| • , • D is a right-associative fold. 

Example 21 Let us attempt a reconstruction of the strategy CF from Figure 5. For 
convenience, we first show the original definition in terms o/Q ( )• Then, we show 
a reconstruction which employs the combinator (|-, •[). 

CP{v, z^o) = (Con; A; Uu) + (FUN; (^^)) 
= (|iv„, (i/, e)]Uo\) 

This reconstruction immediately illustrates why the combinator (| • , • |) is more pow- 
erful than the combinator As the second argument in the above application 
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Syntax 



s ::- 



\s,s\ 



Reduction of strategy applications 
Positive rules 



A ■■■ 

(\so,Sc\)@fiti,...,tn)^t'o 



fold+.l 



[fold+.2] 



S@t^t' 



Negative rules 

so @ ^ T 

(]sO,ScD@C'^^ T 

so @ ^ T 

3i € {l,...,n}. 

so® 0-^4 

A S,@{tnX)^tn-l 
A ... 

A se@(t^,t^)^ r 

(\so,Sc\)@fiti,...,tn)^] 



[fold-.l] 



fold". 2 



fold -.3 



Fig. 28. An intentionally type-unifying traversal combinator for folding the children 



o/ d • , • I) points out, a child is processed independent of the intermediate value of re- 
duction (cf. the congruence {v, e)), and both values are composed in a subsequent 
step by Uo. This is precisely the scheme underlying O (")• 

We cannot type the combinator (|-, D in a simple way in our present type system. 
Consider the intended type of the second argument. The strategy should process 
a pair consisting of a term of any type (corresponding to some child), and a term 
of the distinguished type for type unification. This amounts to the type scheme 
VcK. (a, r) T where r is the unified type for reduction. One could introduce a 
designated generic type for that purpose. Unfortunately, more extensions would be 
needed to effectively use the additional generafity. It is not obvious how to stay in 
a many-sorted setting in this case. Due to these complications we do not attempt to 
work out typing rules for (| • , • D . 



Environments and states There are other useful type schemes than just TP and 
TU( ). In the following table, we repeat the definition of TP and TU( ), and we list 
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Reduction of strategy applications 



TP 



3i G 


s@ 




Ofs) @ f(U tr,) 


fiu 


, . . . , f ^ , . . . J ufij 


TE(.) 






3iG {l,...,n} 






0{s)@{f{tu...,tn),e] 




f(ti, . . . ,t[, . . . ,tn) 


TS(-) 






3zG {l,...,n} 




{U,a)^ {t'„a') 


0(s)@(/(ti,...,y,a 


)^ 


{f{ti,...,t[,...,tn),a') 






Fig. 29. Variants of O(-) 


three further schemes: 






TP = Va. a - 


a 


(Type preservation) 


TU(r) =\/a.a- 


r 


(Type unification) 


TA(r) = Va. (a, 


r)- 


T (Accumulation) 


TE(t) = Va. (a, 


r)- 


-> q; (TP with environment passing) 


TS(t) = \/a.{a, 


r)- 


(a, r) (TP with state passing) 



A strategy of type TA(r) takes a pair {x, a) where x can be of any term type and a is 
of type r, and it returns the resulting value a' of type r. When thinking of traversal, 
TA(t) suggest accumulation of a value whereas the earlier TU(r) rather suggests 
synthesis of a value. Both schemes of traversal are interchangeable, in principle. 
Then, the type scheme TE(r) denotes all strategies that take a pair (x, e) where x 
can be of any term type and e is of type r, and it returns a resulting term x'. When 
thinking of traversal, TE(r) amounts to a combination of type-preserving traversal 
and environment passing. Finally, TS(r) can be regarded as a combination of TP 
and TA(t). In this combination, it is suggestive to speak of state passing. 



Designated combinators vs. monads The ultimate question is how to inhabit 
the above type schemes. S' is not sufficiently expressive to derive traversal com- 
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Library strategies 



Traversals (I) and (II) 



try : tp -> tp . data nat = zero I succ(nat) . 

try(S) = S <+ id. data gsort = c 

I g (gsort) 

repeat : tp -> tp. I gprime (gsort) . 

repeat (S) = try(S; repeat (S)). data other = b (other, gsort) 

I f (other, nat) 

oncebu : tp -> tp . I h(nat, gsort) . 

oncebu(S) = one (oncebu (S) ) <+ S. 

inc : nat -> nat . 
stoptd : tp -> tp. inc = N -> succ (N) . 

stoptd(S) = S <+ all (stoptd (S) ) . 

traverse! : tp . 

traverse! = stoptd (inc < tp) . 

traverse!! : tp . 

traverse!! = oncebu ( (g (X) -> gprime (X) ) < tp) 



Fig. 30. Strategic programs in Prolog 



binators for the additional generic types from the existing combinators that cover 
TP and TU(-). However, it is not difficult to define corresponding variations on the 
existing traversal primitives. Let us illustrate this idea for the generic type TE(-). 
Dedicated traversal combinators should not simply apply a given strategy to the 
children, but an environment has to be pushed through the term, too. Let us char- 
acterise a corresponding variation on O(-). If 0(s) is applied to (/(ti, . . . ,tn), e), 
then the strategy application to rewrite a child is of the form s @ (tj, e). In Fig- 
ure 29, the positive rules for variants of O(-) for TP, TE(-) and TS(-) are shown. 
All other traversal primitives admit similar variations. In a higher-order functional 
programming context, monads [ |Spi90| , |Wad92| ] can be employed to merge effects 
like environment or state passing with the basic scheme of type-preserving or type- 
unifying traversal. Monads would also immediately allow us to deal with reducts 
other than optional terms, namely lists or sets of terms. In the reduction semantics 
of S'^, we hardwired the choice of an optional term as reduct. This choice corre- 
sponds to the maybe monad. 



6 Implementation 



In the sequel, we discuss a Prolog-based implementation of S'^, and we report on an 
investigation regarding the integration of the S'^ expressiveness into the rewriting 
framework ELAN. The Prolog implementation is convenient to verify our ideas 
and the formalisation, but also to prove the simplicity of the approach. We have 
chosen Prolog due to its suitability for prototyping language syntax, typing rules, 
and dynamic semantics (cf. QLROip ). The ELAN-centered investigation backs up 
our claim that the proposed form of generic programming can be easily integrated 
into an existing, basically first-order, many-sorted rewriting framework. 
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6.1 A Prolog prototype 



It is well-known that deduction rules in the style of Natural semantics map nicely 
to Prolog clauses (cf. QDesSSQ ). Prolog's unification and backtracking enable the 
straight execution of a large class of deduction systems. In fact, the Natural se- 
mantics definitions from the present paper are immediately implementable in this 
manner. The judgements were mapped to Prolog in the following manner. Well- 
formedness, well-typedness, static elaboration and reduction judgements consti- 
tute corresponding predicate definitions. Terms are represented as ground and ba- 
sically untyped Prolog terms. Strategic programs are represented as files of period- 
terminated Prolog terms encoding type declarations and strategy definitions. In this 
manner, Prolog I/O can be used instead of parsing. Prolog variables are used to en- 
code term variables in rewrite rules, strategy variables in strategy definitions, and 
term-type variables in type declarations. 



Strategies in Prolog The encoding of strategies is illustrated in Figure 30. On 
the left side, the Prolog encoding for some reusable strategies from Figure 3 and 
Figure 4 are shown. On the right side, the strategies for the introductory traversal 
problems (I) and (II) from the introduction are shown. The rewrite rule to incre- 
ment a natural is for example represented asN -> succ(N). One can see that 
the encoding basically deals with notational conventions of Prolog such as the pe- 
riod "." to terminate a term to be read from a file. The term tp denotes the type 
TP. The data directive is used to declare algebraic datatypes contributing to the 
context r of a strategic program. We do not declare types of term variables since 
it is very easy to infer their types using the non-ground representation for rewrite 
rules. 



Prolog encodings of the judgements The implementation of S'^ is illustrated 
with a few excerpts in Figure 31. We show some clauses for the predicates encod- 
ing the reduction of strategy applications and static elaboration of strategies. The 
left-most excerpt shows the very simple implementation of the combinator □(•) in 
Prolog. Here we resort to the Prolog operator "= . . " to access the children as a 
list, and we employ a higher-order predicate map/ 3 to map the argument strategy 
over the children. In the middle, we show the encoding of the static elaboration rule 
from Figure 25. The right-most excerpt implements the reduction semantics of an 
annotated application of • <l - . It deviates from the formalisation in Figure 25 in that 
we do not assume tagged terms but we rather look up the type of the given term by 
retrieving the outermost symbol's result type from a simple context parameter. 



Prological strategies The proposed implementational model is geared towards a 
direct implementation of the calculus' formalisation in Prolog, that is, judgements 
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Reduction of □(•) 



Elaboration of • < 



Reduction of • < 



apply (G, all (S) , TO, Tl) elaborate (G, S<T, (S:Pi)<T) apply (G, ( S : Tau->_) <_, TO , Tl ) 

TO =.. [F|LO], wtStrategy (G, S,Pi) . TO =.. [F|_], 

map (apply (G,S),L0,L1), f InGamma (F, G, Tau,_) , 

Tl =.. [F|L1]. apply (G, S, TO, Tl) . 

Fig. 31. Implementation of S' in Prolog 



become predicates. Strategic programming can also be integrated into Prolog in a 
more seamless way from the logic programmer's point of view. Essentially, strategy 
combinators can be represented as higher-order predicates. Prolog programmers 
are used to this idea which is for example used for list processing. Furthermore, 
we abandon rewrite rules altogether, and we assume that many- sorted functionality 
is defined in terms of ordinary Prolog predicates. This approach is not just conve- 
nient for logic programmers, but it also leads to a very compact implementation 
of strategic programming expressiveness. In such a Prolog incarnation of strate- 
gic programming, the most complicated issue is typing. In general, all attempts to 
impose type systems on Prolog restrict Prolog's expressiveness to a considerable 
extent. We cannot expect that all the implementations of the strategy combinators 
themselves can be typed-checked. In particular, the use of the univ operator "=.." 
for generic term destruction and construction is hardly typeable. Recall that "=.." 
would be needed for the implementation of traversal combinators. Hence, we need 
an approach where type-checking is optional, that is, it can be switched off maybe 
per Prolog module. We refer to [ |LR01| ] for a discussion of the Prological incarna- 
tion of strategic programming. 



6.2 Integration into ELAN 



The rewriting framework ELAN supports many-sorted rewriting strategies. How- 
ever, generic traversal combinators are not offered. ELAN's type system is indeed 
a many-sorted one. ELAN's module system offers parameterisation of modules by 
sorts. One can import the same parameterised module for different sorts. This leads 
to a style of programming where function symbols and strategy combinators are po- 
tentially overloaded. In the sequel, we explain how combinators for generic traver- 
sal and strategy extension can be made available in ELAN based on the Si^ model 
of typed strategies. The simplicity of the integration model indeed further backs up 
our claim that S'^ is straightforward to implement. We should point out that there 
are ongoing efforts to revise the specification formalism and the system architecture 
underlying ELAN. We base our explanations on ELAN as of DBKK+98|, |BKKR01|] . 



The module strat[X] Let us recall some characteristics of many-sorted strate- 
gies as supported by ELAN. There is a designated library module strat [X] for 
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strategy combinators parameterised by a sort X. In fact, certain ELAN strategy com- 
binators are built-in, but for the sake of a homogeneous situation we assume that 
all combinators are provided by the module strat [X] . ELAN offers a notation 
for strategy application which can be used in the whe re-clauses of a rewrite rule 
and in the user interface. If strategies should be composed and applied to terms of a 
certain sort, one needs to import the module strat [X] where the formal param- 
eter X is instantiated by the given sort. By importing this module for several sorts, 
the strategy combinators are overloaded for all the sorts accordingly. This approach 
implies that parsing immediately serves for type checking. ELAN also allows one 
to define new many-sorted strategy combinators. One can also define combinators 
for the sort parameter of a module so that the definitions are reusable for different 
sorts. As an aside, ELAN's parameterised modules can be used as a substitute for 
type-parameterised strategies in the sense of S' . 



The module any[X] In addition to parameterised modules, ELAN offers further 
means to define generic functionality, that is, functionality dealing with terms of 
arbitrary sorts. We review these techniques to see whether they are suitable for the 
implementation of the S'^ combinators for generic traversal and strategy extension. 
There is a designated library module any [X] which supports a form of dynamic 
typing and generic term destruction / construction per sort X. The module uses a 
universal datatype any in the sense of dynamic typing. The datatype X and any 
are mediated via an injection function defined by the module. Further, the module 
hosts explode and implode functions to destruct and construct terms of sort any. 
The children of a term are made accessible as a list of terms of sort any. Inter- 
nally, ELAN uses a pre-processor to generate the rewrite rules for explosion and 
implosion. 



Naive encoding of S'^ For brevity, we restrict ourselves to type-preserving strate- 
gies in the sequel. S'^ strategies of type TP can be encoded as ELAN strategies of 
type any any. One can define traversal combinators in terms of implosion and 
explosion based on the functionality of the module any [X] . The combinator □(•), 
for example, would be defined in roughly the same manner as in the above Prolog 
encoding. First, the given term of sort any is exploded to access the functor and the 
children. Then, the argument strategy is mapped over the children via a dedicated 
strategy for list processing. Finally, the original functor and the processed children 
are imploded. The combinator for strategy extension can be encoded in ELAN as 
follows. Given a strategy s of type X — > X, strategy extension derives a strategy 
of type any — > any. The application of the extended s entails the attempt to take 
away the injection of type X any from the term at hand. If the given term is 
not of sort X, the application of the extended strategy fails in accordance with type 
safety. The combinator for strategy extension is overloaded for all possible X, that 
is, it needs to be placed in a module parameterised by X. If the strategic program- 
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mer wants to apply a "generic" strategy, (s)he has to inject the given term into any 
prior to application, and to unwrap the injection from the result. 



Fully typed encoding of S'^ The above encoding suffers from the following prob- 
lem. The sort any is exposed to the strategic programmer in the sense that generic 
strategies are known to operate on terms of sort any. Hence, there is no guarantee 
that generic strategies are well-typed in a many-sorted sense. To give an exam- 
ple, an intentionally type-preserving strategy can map a term of sort X to a term 
of sort Y while this type change would go unnoticed as long as terms are repre- 
sented inside the union type any. Furthermore, the exposition of any allows a 
strategic programmer to manipulate compound terms in an inconsistent manner. 
Note that explosion and implosion involves lists of terms. That is, the ELAN type 
system does not ensure that the manipulated exploded terms form valid terms in 
the many-sorted sense. This implies a potential for implosion failure at run-time. A 
fully typed encoding requires the following elaboration of the naive approach. In 
abstract terms, we need to hide the employment of any for strategic programmers 
who want to apply generic strategies, inhabit generic strategy types via strategy 
extension, or define new combinators in terms of the basic combinators. Then, a 
strategic programmer cannot define ill-typed generic strategies, neither can (s)he 
cause implosion failures provided all the basic combinators are implemented in ac- 
cordance with the S'^ reduction judgement that is known to be type-safe. In order 
to hide the employment of any, we assume the introduction of designated sorts 
for generic strategy types where these sorts are known to the strategic program- 
mer but not their definition. To give an example, we assume a sort tp for the S'^ 
type TP with the hidden definition any — > any in ELAN. All the combinators 
for a generic strategy type are defined in a module together with the designated 
sort. Since strategy application and strategy extension work per sort, we need a pa- 
rameterised module, e.g., tp [X] for generic type-preserving strategies which can 
be applied to terms of sort X, and which can be derived by extending many-sorted 
strategies of type X — > X. Clearly, tp [X] can be regarded as an abstract datatype 
(ADT) for generic type-preserving strategies. 

To summarise, the described integration model relies on the following concepts: 

• parameterised modules to overload strategy combinators per sort, 

• type-checking by parsing overloaded many- sorted strategies, 

• dynamic typing to achieve the needed degree of polymorphism, and 

• support for generic term destruction / construction. 

Because these features are present in ELAN, the support of S':I^-like strategies does 
not require any internal modification of ELAN. Instead of relying on features like 
a pre-processor for term implosion and explosion, we could favour an extension 
of the rewrite engine to directly support traversal combinators, and strategy exten- 
sion as well. This approach would be, in general, appropriate to implement S' - 
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like strategies in other frameworks for rewriting or algebraic specification, e.g., in 
ASF+SDF [IBHK89L [Kli93i |BHJ+01|1. 



7 Related work 



Specific pointers to related work were placed in the technical sections. It remains 
to comment on related work from a more general point of view. First, we relate S'^ 
to existing strategic rewriting calculi. Then, we discuss other efforts in the rewrit- 
ing community to enable some form of generic programming. Finally, we discuss 
genericity in functional programming because this paradigm is very much related 
to rewriting. 



7.1 Strategic rewriting calculi 



Let us relate the calculus S!^ to those frameworks for strategic programming which 
were most influential for its design, namely system S underlying Stratego [ |VB98| , 
VBT98D, and ELAN [|BKK+98|, lEKKROip. 



S'^ vs. system S and Stratego Our typed rewriting calculus S'^ adopts the un- 
typed system S* to a large extent. We stick to the same semantic model. We also 
adopt its traversal combinators □(■) and O(-). System S suggests a hybrid traversal 
combinator O(-) where the application of the argument strategy has to succeed for 
at least one child but the application is attempted for all children. We leave out O • in 
S'^ in order to minimise the operator suite which needs to be covered by the formal- 
isation. The main limitation of S'^ compared to system S is that we favour standard 
first-order rewrite rules with where-clauses as primitive form of strategy. By con- 
trast, system S provides less standard primitives which are however sufficient to 
model rewrite rules as syntactic sugar. These primitives are matching to bind vari- 
ables, building terms relying on previous bindings, and scoping of variables. The 
additional flexibility which one gains by this separation is that arbitrary strategies 
can be performed between matching and building. One can simulate this style by 
using where-clauses in S'^. The key innovation of S'^ when compared to system 
S is the combinator ■ < • for strategy extension. Since the combinator ■ < • relies 
on a type-dependent reduction semantics, one cannot even expect any combinator 
like this in untyped systems such as Stratego or system S. Furthermore, Si^ also 
introduces combinators which are not expressible in system S, namely the combi- 
nators O (■) ^iid tj(-) for intentionally type-unifying traversal. Stratego provides a 
combinator which can be used to encode type-unifying traversal, namely This 
combinator is meant for generic destruction and construction of terms very much 
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in the style of the standard univ operator "=.." in Prolog. Interestingly, the com- 
binators □(•) and <>(■) could be encoded in terms of A crucial problem with 
is that it leads to a hopelessly untyped model of traversal since the programmer 
accesses the children of a term as a list. While the system S combinators □(•) and 
O(-) suggest a typeful treatment, typeful type-unifying strategies cannot be based 
on but other combinators are needed. This is the reason that we designed the 
traversal combinators O (') ^^id tj(-) for type-unifying traversal in S' . 



S!y vs. ELAN The influence of ELAN is also traceable in S*^. We adopt the model 
of rewrite rules with where-clauses from ELAN. We also adopt recursive strategy 
definitions from ELAN while system S favours a special recursion operator fi ■ . ■. 
In the initial design of a basically many-sorted type system we also received inspi- 
ration from the ELAN specification language. ELAN and S'^ differ in the semantic 
model assumed for reduction. ELAN offers a faithful model of non-determinism 
via sets or lists of possible results where the empty set represents failure. The type 
system of S'^ does not rely on the simple model of system S. In fact, our typeful ap- 
proach to generic traversal could be integrated with the ELAN-like semantic model 
without changing any detail in the type system. 



7.2 Genericity in rewriting 



], polytypic entities are defined in terms of the reflection and meta- 
programming capabilities of Maude. This approach is hard to compare with S'^ 
which is based on the idea of static typing and a designated type system. Further- 
more, the mixture of many-sorted and generic functionality is not considered. Also, 
the Maude approach — as any other polytypic approach — does not propose traversal 
combinators but traversal is based on polytypic induction. 



In [ JBKVOip , a fixed set of traversal strategies is supported by so-called traversal 
functions extending the algebraic specification formalism ASF [ |BHK89fl . The cen- 
tral idea is to declare designated function symbols for traversal according to pre- 
defined strategies for top-down, bottom-up and accumulating traversal. The pro- 
grammer refines a traversal function by rewrite rules for specific sorts. This ap- 
proach is less general than the S!y approach because the programmer cannot de- 
fine new traversal schemes. Also, it is more difficult to separate many-sorted and 
generic functionality. However, this approach is sufficient for many common sce- 



narios in program transformation and analysis [ |BKV01| , |LW01| ]. In fact, traver- 
sal functions are very convenient to use because of their seamless integration into 



ASF-i-SDF [BHK89, Kli93, BHJ+01]. 



In [ pKKROip , dynamic typing [ |ACPP91| , |ACPR92D and generic implosion / explo- 
sion a la Prolog's "=.." are used to traverse terms. Dynamics tend to spread all over 
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a program which clearly goes against a many-sorted typing discipline. Also, the 
use of explosion and implosion in a program implies a basically untyped manipula- 
tion of exploded terms. Furthermore, basic traversal combinators are not identified. 
Their benefits were first identified in the early work on Stratego [ |LV97| ]. We al- 
ready explained in Section 6.2 how ELAN's features can be used to implement the 
S'^ combinators in a typeful manner. The formalisation of 5"^ avoids all kinds of 
typing problems in the first place because terms are not converted to a universal 
type. 

We envision that the design of S'^ could be useful in the further elaboration of other 
formal models for rewriting so that typed generic traversal will be covered. One 
prime candidate is the p-calculus [ |UK99| ] which provides an abstract and very gen- 
eral formal model for rewriting including strategies. Generic traversal combinators 
have been defined in the p-calculus (cf. ^(s) and $(s) in [ |CK99| ] corresponding to 



□ (s) and 0(s)) but these definitions cannot be typed in the available typed frag- 



ments of the p-calculus QCKLOIQ . There is ongoing research to organise typed cal- 



culi in a so-called p-cube, very much in the sense of the A-cube [|Bar92|] . It is not 



obvious how certain typing notions interact with each other if we attempt to cover 
generic traversal in this cube, e.g., type-dependent reduction a la S'^ vs. dependent 
types. 



7.3 Genericity in functional programming 



The most established notion of genericity or polymorphism is certainly parametric 
polymorphism [ |Mll7B| , |Gir7^ |Rey74| , |Rey83| , |CW85| , It is clear that para- 

metric polymorphism is not sufficient to model typed generic traversal strategies. 
Firstly, it does not allow us to descend into terms. Secondly, parametric polymor- 
phism is also in conflict with non-uniform behaviour as it can be assembled in terms 
of strategy extension. Several forms of polymorphism were proposed that go be- 
yond parametric polymorphism, namely dynamic typing [ |ACPP91| , |ACPR92[ ], ex- 
tensional polymorphism [ pRW95[ l, intensional polymorphism [ |hlM95[ J, and poly- 
typism [ p97[ ] . A general observation is that none of the available systems subsumes 
5":!^. Dynamic typing was already discussed in the previous section on rewriting. The 
remaining forms are reviewed in the sequel. We also refer to QLVOO| , |LV01| ] where 
we report on actual efforts to encode generic traversal strategies as generic func- 
tions. 



Let us check the requirement for generic traversal, that is, the ability to descend into 
terms. Clearly, algebraic datatypes model sets of typed terms in functional program- 
ming. Extensional polymorphism, intensional polymorphism and polytypism have 
in common that they offer some form of generic function definition based on struc- 
tural pattern matching on types. These forms can be used to encode traversal. In the 
cases of extensional and intensional polymorphism, type-based induction involves 
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cases for basic datatypes, products and functions. The mere structure of algebraic 
datatypes implies that a case for sums is also needed. In fact, polytypic program- 
ming considers algebraic datatypes as sums of products, and adds a corresponding 
pattern for type induction. It would be straightforward to extend extensional and 
intensional polymorphism accordingly. 

The idea of strategy extension implies that generic strategies are aware of many 
sorts, say systems of named algebraic datatypes in the sense of functional program- 
ming. However, all the aforementioned forms of polymorphism are geared towards 
structural induction on types, that is, they do not involve a notion of checking the 
coincidence of two (names of) types as it is required for strategy extension. This 
crucial difference is discussed in [ |Gle99B . This shortcoming has been addressed in 



recent work on polytypic programming to some extent, namely different propos- 
als for Generic Haskell include support for some form of type- specific cases (cf. 
ad-hoc definitions in []Hin99|]) in an otherwise structural induction on types. 



In fact. Generic Haskell appears to offer the most complete feature list for an en- 
coding of rewriting strategies because generic term traversal and specific type cases 
are offered by the language design of Generic Haskell. However, we cannot recon- 
struct 5";!^, in this language setup for the following reasons. Firstly, polytypic func- 
tions are not first-class citizens. In particular, one cannot pass a polytypic func- 
tion as an argument to another polytypic function. First-class functions are needed 
to model traversal combinators, traversal schemes or other parameterised strate- 
gies. Secondly, type case is based on polytypic function definition as a top-level 
form of declaration. This restricts the separation and composition of type-specific 
vs. generic functionality. More generally, polytypic programming does not support 
combinator style of generic programming whereas strategic programming relies on 
combinator style. 



8 Conclusion 



Typed generic traversal strategies In the present paper, we developed a typed 
calculus S'^ for term rewriting strategies. The main contribution of the paper is that 
generic traversal is covered. The idea of generic traversal combinators is already 
present in previous work on strategic rewriting, however, only in untyped settings. 
It turned out that existing combinators for intentionally type-preserving traversal 
could be easily typed. However, the typical approach to type-unifying traversal is 
hopelessly untyped (cf. generic term destruction and construction a la in Strat- 
ego, "=.." in Prolog). To resolve this problem, we proposed designated traversal 
combinators for type-unifying traversal. The key idea underlying our type system 
is the 5':^-like style of type-safe extension of many-sorted strategies. This approach 
allows us to combine many-sorted and generic functionality in a very flexible man- 
ner without confusing different kinds of strategy composition (cf. ■ < ■ vs. ■ ■)• 
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The type system separates many-sorted and generic strategies in a way that the 
precision of the underlying many-sorted type system is preserved. 



Simple generic programming At a design level, our declared goal was to ob- 
tain a simple, self-contained model of typed generic traversal on the grounds of 
basically many-sorted, first-order term rewriting. In fact, the type system of S'^ 
is simple, and the complete calculus is straightforward to implement. To explain 
what we mean by "simple type system" and "straightforward implementation", we 
mention that the development of the Prolog prototype, which we discussed earlier, 
took two days. Contrast that with other approaches to generic programming such 
as PolyP and Generic Haskell which usually require(d) several man years of de- 
sign and (prototype) implementation. Generic term traversal based on the designed 
suite of traversal combinators is very potent but it certainly does not cover the 
full range of generic programming (cf. kind-indexed polytypic definitions, generic 
anamorphisms, and others). Also, the overall setting of S'^, especially the restriction 
to a basically first-order, many-sorted setting, rules out several powerful program- 
ming idioms, e.g., higher-order functions. Nevertheless, the prime justification for 
the restricted approach is the well-defined application domain covered by the cho- 
sen expressiveness, namely program transformation and analysis for large language 
syntaxes (cf. 0VBT98| , ICVODj f7i^ |BKV01| , FVOTI ]). 



Functional strategies In our ongoing work, we transpose strategic term rewriting 
to the functional programming paradigm (cf. the Haskell-based generic program- 
ming bundle Strafunski; see |http : / /www .cs.vu.nl/Stra fun ski/] ). In [ |LVU1| ], 
we motivated and characterised a corresponding notion of functional strategies, and 
we provided a corresponding combinator library for generic functions. This ap- 
proach complements existing approaches to generic functional programming in that 
it supports first-class generic functions which can traverse into terms of systems of 
algebraic datatypes while mixing uniform and type-specific behaviour. In fact, we 
investigate different models to support strategies in functional programming. One 
model which we also discuss in [ |LV01| ] is based on the formula "strategies as func- 
tions on a universal representation type" as discussed for ELAN in Section 6.2. 



Future work Besides the notion of functional strategies, we are also interested in 
the further development of the strategic rewriting paradigm in general. We indicate 
an open-ended list of challenges for future work: 

• Typed-based optimisation of traversals. 

• Typeful treatment of impure extensions of Stratego. 

• Fusion-like principles for traversal strategies [ pV01| ]. 

• Systematic derivation of one-step traversal combinators. 

• Interaction of constraint mechanisms and traversal strategies. 



79 



Application of strategic programming to document processing. 
Coverage of generic datatype-changing transformations [ |LL01| ]. 
More precise types as for success and failure behaviour [ |Mor99| ] . 
More precise types as for kinds of involved polymorphic behaviour. 
Coverage of generic term construction in the sense of anamorphisms. 
Comparison of attribute grammar approaches and strategic programming. 
Comparison of strategic programming and adaptive programming [ |LPS97| ]. 
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